> Le 17 août 2017 à 17:36, Jeffrey Walton <noloa...@gmail.com> a écrit : > > On Thu, Aug 17, 2017 at 11:34 AM, Erwann Abalea > <erwann.aba...@docusign.com> wrote: >> >>> Le 17 août 2017 à 17:26, Jeffrey Walton <noloa...@gmail.com> a écrit : >>> >>>>> When you see a name like "example.com" in the CN, its usually a CA >>>>> including a domain name and not a hostname. >>>> >>>> That's nonsense. >>> >>> If a certificate is issued under CA/B policies, and CN=example.com but >>> it _lacks_ SAN=example.com, then its a not a hostname and it should >>> not be matched. >> >> Such a certificate would be mis-issued and be revoked immediately. CN MUST >> be an FQDN (or a wild carded FQDN, or an IP address), and a copy of the >> value in CN MUST be present in the SAN extension. > > Oh, you would have some fun watching how various user agents handle > that scenario. For your first stop, check out how OpenSSL handles it.
I’m sure some user agents can have strange behaviors on such certificates. My remark took into consideration the CA/B policies. If such a certificate falls down under the CA/B policies (issued by a public CA, and a TLS server certificate), then it’s invalid. Some browsers (maybe all?) ignore the CN if the SAN extension is present, even for private CAs. Cordialement, Erwann Abalea -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
