Skip navigation
1502 Views 1 Reply Latest reply: May 28, 2012 2:15 AM by Ivan Ristic RSS
j457 Level 1 21 posts since
May 26, 2012
Currently Being Moderated

May 26, 2012 9:09 PM

Two common names results in mismatch?

I generated a certificate like this:




        Version: 1 (0x0)

        Serial Number: ...

    Signature Algorithm: ecdsa-with-SHA256

        Issuer: C=..., ST=..., L=..., O=..., CN=www.<domain>.com, CN=<domain>.com


            Not Before: ...

            Not After : ...

        Subject: C=US, ST=..., L=..., O=..., CN=www.<domain>.com, CN=<domain>.com

        Subject Public Key Info:

            Public Key Algorithm: id-ecPublicKey

                Public-Key: (384 bit)



                ASN1 OID: secp384r1

    Signature Algorithm: ecdsa-with-SHA256



The important part being the two CNs.  When I run sslcheck against (the canonical form), it says there's a mismatch.


However, Chrome doesn't complain about the mismatch.  It only warns that the cert is self-signed and untrusted.


If I generate a different cert using and literally, and set the webserver to use that one, I get both warnings: untrusted (because self-signed) and not matching the url.


I realize that CAs tend to use subjectAltName to do this, but is there any reason why multiple CNs for multiple hostnames shouldn't work, or why the qualys SSL checker considers it a mismatch?


I even generated and used a new cert with the order of the two CNs reversed.  Chrome still doesn't mention a mismatch*, while qualys still considers it a mismatch.


*Something weird happens with chromium on linux, where it does say there's a mismatch, but perhaps that's because I haven't restarted chromium there.  On windows, and after restarting chrome just to be sure, it considers the domain to match regardless of CN order.

  • Ivan Ristic Level 4 488 posts since
    Jul 23, 2010
    Currently Being Moderated
    May 28, 2012 2:15 AM (in response to j457)
    Two common names results in mismatch?

    The thing about multiple common names, is that, until recently (RFC 6125), there was no standard saying what should and shouldn't be done. As a result, I believe you are going to see inconsistent behaviour across client SSL tools. Some may try to match against all listed CNs, some against the first, some against the last. Maybe that's what's you're seeing on Chromium on Linux. I think that using alternative names is a safer approach.

    EV certificates explicitly allow multiple CNs. Because of that and legacy, RFC 6125 (see section 7.4) grudgingly allows the use of multiple CNs, but recommends against this practice.


    SSL Labs requires a single CN (becase I built it before the RFC and I took a strict stance), but after RFC 6125 had came out I opened a ticket to replace failure with a warning (about possible deployment issues).


    Thanks for reminding me of this issue. I will fix it in our next major release.

More Like This

  • Retrieving data ...

Bookmarked By (0)


  • Correct Answers - 10 points
  • Helpful Answers - 6 points