It amuses me when Google dictates security policy.
Beginning with Chrome 58, the Chrome browser no longer uses the Common Name (CN) field to validate an SSL certificate. Instead, it only uses the Subject Alternative Name field.
This is in violation of
RFC 2828 which states,
If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.
So someone in Google security said, "Hey! If RFC 2828 says the Common Name is deprecated, we should start making Chrome ONLY use the Subject Alternative Name! Existing practice, be damned." Never mind the fact that the RFC was written May 2000, and every other browser and app on the planet uses the Common Name field for single-name certificates.
Therein lies the problem. Most single name certificates and some wildcard certificates only have a Common Name and don't have use Subject Alternative Names. This causes Chrome 58 and later to display the following (incorrect) error. It even goes so far as to blame it on a server misconfiguration.
|
NET::ERR_CERT_COMMON_NAME_INVALID [missing_subjectAltName] |
This same website (in this case, OWA) displays properly in all other browsers. If we look at the certificate, we see this is a wildcard cert for
*.contoso.com issued by an internal certification authority (CA). The Details tab shows there is no Subject Alternative Name field for this cert.
|
Wildcard certificate details with only a Common Name (CN) field |
To fix the error for your Chrome users, you'll need to regenerate the certificate to include a Subject Alternative Name. Here's how to do that using the Certificates MMC when you have an internal Certification Authority (CA).
From the web server, open MMC and add the
Certificates snap-in, managing the Computer account. Then expand
Certificates (Local Computer) >
Personal >
Certificates.
|
Right-click Certificates > All Tasks > Request New Certificate. |
|
Choose Active Directory Enrollment Policy to use your existing internal CA. |
|
Select the Web Server certificate template and click the link below it to enter more information. |
|
Add the Common Name for the Subject Name, and the DNS name for the Alternative Name. They can be the same value. Chrome 58 and later only uses the DNS alternative name. |
|
Enter a Friendly Name on the General tab. |
|
Optionally, make the private key exportable on the Private Key tab and click OK. |
|
Click Enroll to generate the new cert from the CA and install it on the web server. |
|
The certificate will be installed. Click Details to view the new certificate. |
|
On the Details tab we see the Subject Alternative Name is on the new cert. |
Now you'll either need to configure IIS to use the new certificate (Web Site - Bindings) or reconfigure Exchange web services using the Enable-ExchangeCertificate cmdlet.
No comments:
Post a Comment
Thank you for your comment! It is my hope that you find the information here useful. Let others know if this post helped you out, or if you have a comment or further information.