Tag: cn

超長網域名稱會遇到的 TLS certificate 問題

在「L(O*62).ONG: Make your URL longer (looooooooooooooooooooooooooooooooooooooo...)」這邊看到的有趣東西，網站是「L(o*62).ong - Make your URL longer」，網站的主人還在搞事就被貼到 Hacker News 上，所以他就上來說明一下發生了什麼事情...

在 id=40543697 這邊提到網域名稱過長導致撞到 TLS certificate 中 commonName (CN) 欄位長度限制的問題：

The longest segment of a domain name is 63 characters. The maximum length of an HTTPS certificate commonName is 64 characters.

This caused Cloudflare, Vercel, and Netlify to be unable to use Let's Encrypt to sign HTTPS certificates (because they used the domain name as the commonName), but Zeabur can use Let's Encrypt to sign HTTPS certificates.

Finally, the Cloudflare certificate was switched to Google Trust Services LLC to successfully sign.

不過後面有人提到 commonName 在網頁用的 TLS certificate 已經 deprecated 很久了，而 Let's Encrypt 在 2023 年的時候已經支援 commonName 留空，改用 Subject Alternative Name，可以到 255 chars。

留言裡面所連結的 Let's Encrypt 公告上面也提到了類似的事情：「Simplifying Issuance for Very Long Domain Names」。

Additionally, the CN is limited to at most 64 characters, while SANs can be significantly longer. This means that the CN is not only redundant, but actively restrictive: a certificate which has a Common Name cannot contain only very long domain names, because none of them would fit in the CN. For these reasons, the BRs state that for Domain Validated certificates, the Common Name field is "not recommended".

所以看起來是各家系統還沒有跟著改 (因為 Let's Encrypt 先前需要 CN 有值)，但如果是自己申請的應該是可以自己避開了 (生 csr 的時候就改用 SAN)？

iOS 13 與 macOS 10.15 對憑證的限制

在 Slack 上看到同事丟出來的，關於之後要推出的 iOS 13 與 macOS 10.15 會對憑證限制的項目：「Requirements for trusted certificates in iOS 13 and macOS 10.15」。

主要是把不安全的演算法淘汰掉 (RSA 小於 2048 bits，以及 SHA-1 類的 hash algorithm)，這兩個部份相關的新聞應該不少，沒有什麼太大問題：

TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS.

TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm. SHA-1 signed certificates are no longer trusted for TLS.

然後是要求憑證使用 SAN (Subject Alternative Name)，舊的標準 CN (CommonName) 將不會再被信任。

如果是公開簽發的憑證應該都沒問題 (像是 Let's Encrypt，或是花錢買的那些)，主要的問題應該會出現在自己建立的憑證，網路上蠻多舊資料還是產生 CN...

TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted.

另外是 2019/7/1 之後發出的憑證，有額外兩個規範要注意，第一個是強制要透過 EKU 指定 id-kp-serverAuth，這是出自 RFC 5280：

   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   -- keyEncipherment or keyAgreement

TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.

再來是時間的限制，接下來的憑證最長只認得 825 天 (大約 27 個月多一些)，以前都惡搞 -days 3650，現在得兩年簽一次了：

TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).

整體看起來主要是影響自己簽的部份...