擁有與 SSL 證書 CN 不匹配的 CNAME 是不好的做法嗎？

劇情是這樣的……

$ openssl x509 -subject -noout -in cert.crt
subject= /CN=example.org

$ curl -I "https://example.org"
HTTP/1.1 200 OK

$ dig example.org
example.org.           60      IN      A       192.0.2.1

$ dig foo.example.org
foo.example.org.       60      IN      CNAME   example.example2.com.
example.example2.com.  60      IN      A       192.0.2.1

$ curl -I "https://foo.example.org"
HTTP/1.1 200 OK

$ curl -I "https://example.example2.com"
curl: (51) Unable to communicate securely with peer: requested domain name does not match the server's certificate.

使用別名時，foo.example.org我看不到 CNAME example.example2.com。因此，CNAME 與證書名稱不匹配並不重要。

但是有人問我應該使用這三個名字中的哪一個。我的回答是除了example.example2.comSSL 之外，這三個都可以使用。

從最終使用者的角度來看，這對我來說似乎很奇怪。證書告訴我example.org是受信任的名稱，但該組織在域中的記錄example.org告訴我一個不受信任的名稱 - 在不同的域中 - 是一個規範（官方）名稱。

還有，example.org並且example2.com有 SOA 記錄。帶有子域的名稱不會有 SOA 記錄。我不確定 SOA 記錄是否與應該被視為合理的規範名稱有任何關係。

首先，為了確保證書驗證本身沒有混淆，DNS 不是證書主體名稱驗證過程中的一個因素。

HTTPS 客戶端不需要知道或關心CNAME名稱解析過程中是否遇到記錄。它只使用 URL 主機名對應的 IP 地址來建立連接，然後在驗證伺服器提供的證書有效時直接比較 URL 主機名和主題名。

至於“三個名字應該用哪個？”的問題。如果服務/站點的所有者只決定應該使用一個名稱，並讓每個人都清楚地使用該名稱，那麼他們就可以省去一些麻煩。

如果這是關於網站的，通常會為對替代名稱的任何請求設置 HTTP 重定向，將這些請求重定向到首選名稱（這將很好地說明首選名稱）。

如果這是關於重定向不會真正起作用的 API 或其他服務，則可能至少在服務描述/文件中提供了首選名稱。

人們還可以合理地期望首選名稱具有有效的證書，以便客戶端可以使用 HTTPS（非正常範）。

我故意避免使用“規範名稱”一詞，以使這種推理與CNAME記錄類型明確分開。

如果沒有額外的知識，CNAME您看到的任何記錄只能被認為是對域所有者希望解析器遵循以完成查找的不同名稱的引用。

這方面的“規範名稱”方面已在很大程度上失去了，因為CNAME記錄被普遍用作提供通用間接目的的黑客手段（通常在SRV理論上有意義但客戶端不知道的地方SRV，如普通 HTTP /HTTPS 客戶端）。

引用自：https://serverfault.com/questions/989302