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

Two common names results in mismatch?

j457

I generated a certificate like this:

 

Certificate:

    Data:

        Version: 1 (0x0)

        Serial Number: ...

    Signature Algorithm: ecdsa-with-SHA256

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

        Validity

            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)

                pub:

                    h:e:x

                ASN1 OID: secp384r1

    Signature Algorithm: ecdsa-with-SHA256

         h:e:x

 

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

    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.

    • Re: Two common names results in mismatch?
      P J

      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

      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

            extension.

      -> Wich ?