Original link: https://zdyxry.github.io/2023/03/25/%E8%AF%81%E4%B9%A6-CommonName-%E5%92%8C-subjectAltName-%E7%9A%84% E5%85%B3%E7%B3%BB/
The background is linked to the title. Because the certificate used by HTTPS in the product is a self-signed certificate, which does not meet the security requirements of some scenarios, a user certificate needs to be imported. This change itself is very easy, just need to specify the certificate according to the Nginx official document configuration, but encountered a special scenario: there are 3 nodes in the cluster, each node user is configured with a corresponding Domain Name, and there are VIPs in the cluster ( Virtual IP Address), the user configures the corresponding Domain Name for the corresponding VIP. When the user issues a certificate, the CN (CommonName) used is the Domain Name corresponding to the VIP, and the subjectAltName is the Domain Name of the three nodes in the cluster. At this time, if you access through the corresponding Domain Name of each node, the certificate is valid, but if you access through the corresponding Domain Name of the VIP, the certificate is invalid (due to the special environment, no specific error prompt can be seen).
In my impression, CommonName must specify the corresponding Domain Name, and subjectAltName is a supplement to CommonName, so this phenomenon feels unreasonable, and then I checked relevant information for investigation.
GPT4 link to the title Before the investigation, according to the current mainstream operation, in case of indecision, first ask GPT, so I got the following answer, which is also in line with my understanding:
ask:
In the https certificate, if the CommonName must exist in the SubjectAltName? If CommonName and SubjectName exist at the same time, which one is used as the unique identification check?
answer:
In HTTPS certificates, CommonName (CN) and Subject Alternative Name (SAN) are fields used to identify the domain name represented by the certificate. In early SSL/TLS certificates, CommonName was usually used to represent a single domain name associated with the certificate. However, over time, the Subject Alternative Name extension became widely adopted, which allows certificates to be associated with multiple domain names and subdomains.
Technically, the CommonName does not necessarily need to appear in the Subject Alternative Name list. However, in practice, many modern browsers and clients check the Subject Alternative Name field first, and only check the CommonName field if no matching domain name is found. Therefore, to ensure the compatibility and correctness of the certificate, it is recommended to include the CommonName in the Subject Alternative Name field.
This article is reproduced from: https://zdyxry.github.io/2023/03/25/%E8%AF%81%E4%B9%A6-CommonName-%E5%92%8C-subjectAltName-%E7%9A%84% E5%85%B3%E7%B3%BB/
This site is only for collection, and the copyright belongs to the original author.