Share:|

Chrome 58 has recently dropped into Stable, and it happens to be my browser of choice on Windows, Android and Fedora. A change has come in how a certificate's Common Name is being interpreted.

 

Historically, The CN part of the Subject field  was used to specify the DNS address of the server you were connecting to, such as:

 

Subject: C=GB, ST=England, L=London, O=Smithnet, OU=Smithnet IT, CN=www.smithnet.org.uk/emailAddress=web@smithnet.org.uk

 

The x509 v3 extension provided a Subject Alternative Name field, which could be used to specify several different DNS entries, such as:

 

X509v3 Subject Alternative Name:

    DNS:www.smithnet.org.uk, DNS:smithnet.org.uk, DNS:pooh.smithnet.org.uk

 

But, if you didn't need alternatives, you didn't need to use this field. Except, apparently (I was not previously aware) for some time this behaviour was deprecated and  we were not supposed to be using the CN/Subject field: the SAN field was to be used even if only one entry was required.

 

Chrome is now enforcing this: so if you have an otherwise perfectly good certificate, that only has CN but no SAN, you will get a NET::ERR_CERT_COMMON_NAME_INVALID error:

 

CN_INVALID.jpg

 

You can of course use the Advanced link to add an exception.

 

Now, Discovery's Certificate Signing Request creation does not currently have any mechanism to support SANs. I am hoping a new feature to be released in the next major product release, but of course I can't guarantee that. Regardless, your CA that signs CSRs should be able to add the appropriate single-SAN entry even if the CSR doesn't contain any SAN data - but if it doesn't - you should now know why you get the above error.