3 Replies Latest reply on Feb 10, 2016 10:28 AM by tlussnig

    Two common names results in mismatch?

    j457 Level 1

      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 domain.com (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 www.domain.com and domain.com 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.

        • Two common names results in mismatch?
          Ivan Ristic Level 5

          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.

          1 of 1 people found this helpful
            • Re: Two common names results in mismatch?
              P J Lurker

              well it clearly has a SHOULD NOT, meaning

              "there may exist valid reasons in particular circumstances when the

                particular behavior is acceptable or even useful, but the full

                implications should be understood and the case carefully weighed

                before implementing any behavior described with this label."


              in short anyone who uses a SHOULD not must be prepared even for it not to work, because it might not be in other software.

              so it failing isnt really a problem even though it might annoy customers.


              the more intresting question is compatibility with it and maybe if that one has a bad compatibility, which is more than understandable, to pull points from the cert if used.

              • Re: Two common names results in mismatch?
                tlussnig Level 2

                RFC 6125 Sec 7.4

                > however, it explicitly discourages multiple CN-IDs

                  it explicitly discourages multiple CN-IDs.  Although it would be

                > preferable to forbid multiple CN-IDs entirely, there are several

                > reasons at this time why this specification states that they

                > SHOULD NOT (instead of MUST NOT) be included:


                RFC refferes to EV-CERTS(CA/B Version 2.1)

                Current version (https://cabforum.org/wp-content/uploads/EV-V1_5_7.pdf)

                Say under 9.2.3 decprecated and discouraged to multiple CN's.


                > At least one significant certification authority is known to issue certificates containing multiple CN-IDs.

                -> Who ? Is this still valid ?


                > Many service providers often deem inclusion of multiple CN-IDs

                      necessary in virtual hosting environments because at least one

                      widely deployed operating system does not yet support the SNI


                -> Wich ?