Thursday, January 31, 2019

PKI: err_cert_common_name_invalid

Some time ago, users I support were encountering error messages with the following error code when accessing certain websites:

net :: err_cert_common_name_invalid

Note: I have screenshots with the complete message below.

This is because some browsers now manage what is called the "common name" of a SSL/TLS certificate differently.

According to RFC2818, a subject alternative name (subjectAltName - sometimes called "SAN") must be used when validating the identity of a website. In other words, the domain name of the website should match at least one of the subject alternative names in the corresponding field of the certificate. This assumes, of course, that the certificate has at least one subject alternative name.

In reality, some certificates only have a "Common Name" (or "CN") in the subject field.

The RFC notes that:

"Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead."

https://tools.ietf.org/html/rfc2818

RFC2818 was published in May 2000 but most browsers would still check the common name in the absence of subject alternative names. Until 2017 that is. Chrome dropped support for common name checking with version 58. Firefox removed support with version 48. At this time, Internet Explorer and Edge will still accept the common name if no subject alternative names are present.

Besides websites in general, users would encounter this type of error when submitting a certificate request via the web interface of the issuing CA (certificate authority) server.

Note: I will assume knowledge of common PKI terminology here.

That's right: the certificate for the issuing CA server contained no subject alternative names. I recreated the situation in a test environment and you can see, below, what users saw.

With Chrome (version 71) we see this:







If we click on "Advanced", we have more options and can choose the continue to the site:








With Firefox (version 65), we see the following error message and have to option to add an exception:






With Edge (on Windows 10), there is no error message:






How can we eliminate these error messages?

We must request a new certificate for the issuing CA server that I'll simply call the "CA" for the rest of this post. This certificate must have at least one subject alternative name (SAN). In our scenario, we can create the request and issue the certificate on the CA itself. Once the new certificate is issued, we will bind it to the website that users access to request and obtain their certificates.

There may be other methods (certutil at the command line, for example), but I will opt for the "Certificates" (Local Computer) snap-in that I've added to a Microsoft Management Console (MMC). I follow the path shown in the screenshot below to create a "Custom Request":





We click "Next" here:



And here:




And then select an appropriate template (for this purpose, one for server authentication) - and click "Next" once more:




At the next step, we click on "Details" and then "Properties":




This (below) is where we add a SAN to the certificate. Besides the common name, I select "DNS" for "type" and enter the FQDN of the server (there may be other combinations, but I know this works - as we will see later):




I then save the (offline) request as a .req file:




Next, we'll open the file in Notepad and copy the content, including the header and footer:




We then open the CA website and submit our request as shown below:











At this point, we have to issue the certificate and then repeat the first part of the process but select "View status of a pending certificate request".

So (as the administrator of the CA server), we issue the requested certificate:



Note: once again, I assume the reader is familiar with the workings of PKI and would know where to go to issue the requested certificate.


And then, back at the web interface, we download the certificate:











Once we have downloaded the certificate (all this happens on the same server, that is, the issuing CA), we import the certificate into the local computer certificate store of that server:




We browse to the location where we downloaded the certificate:




The "personal" certificate store mentioned below is that of the local computer:




And we complete the wizard by clicking on "Finish":




Note that the new certificate has not only a common name but now includes a subject alternative name:




Lastly, we have to bind the new certificate (with the SAN) to the CA website (usually the default). So we right click on "Default Web Site" and select the option "Edit Bindings" in the menu:



We select "https" (since it's https that uses SSL certificates) among the site bindings and then click on "Edit":



I select the new SSL certificate (which happened to be all lower-case so I was able to distinguish it from the old certificate which was a mix of upper and lower case):




After clicking OK (etc.), I reset IIS at the command line with this command:




***


The new certificate eliminates the error message about...

net :: err_cert_common_name_invalid

But there must be an order in which error messages are displayed because another error message now displays. This time, it has to do with a "weak signature algorithm" which is something I may address in another blog post.