|
We had an issue a few days ago when people with the newest version of Chrome were seeing security errors on our internal sites which were using SSL certificates signed with our internal CA. This turned out to be caused by Google adhering
to RFC2818, which says: If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. Our certificates, of course, only contained the Common Name (CN), with no subjectAltName (SAN). I solved the problem by creating new certificates and hacking openssl.cnf to request a SAN in the CSR. Now, our CA isn’t openssl-based (it’s Microsoft), but it’s occurred to me that openssl-created certificates should really include the site ID in a SAN as well as in the CN. RFC2818 has been out since May, 2000, so I’m rather surprised that
this hasn’t been widely implemented before now. I note that certificates we get from Symantec have lately included a SAN, but I think that’s quite recent. Is there any chance of this being included in openssl? This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this mail in error please notify the postmaster at dor.state.ma.us. |
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
