[openssl-users] Implementing deprecation of commonname and emailaddress

Erwann Abalea Erwann.Abalea at docusign.com
Thu Aug 17 16:45:03 UTC 2017


> Le 17 août 2017 à 17:36, Jeffrey Walton <noloader at gmail.com> a écrit :
> 
> On Thu, Aug 17, 2017 at 11:34 AM, Erwann Abalea
> <Erwann.Abalea at docusign.com> wrote:
>> 
>>> Le 17 août 2017 à 17:26, Jeffrey Walton <noloader at 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



More information about the openssl-users mailing list