Fri 25 Jul 2008 12:35:37 PM UTC, original submission:
Hello,
according to RFC2818 (May 2000), the Common Name of a certificate is to be ignored during certificate validation if one or more subjectAltName:DNS fields is present. In this case, the set of subjectAltName:DNS is to be used to validate the expected host name. Section 3.1:
"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."
All browsers I know honour this clause.
At the URL https://pki.edugain.org/edugainca/crl/cacrl.pem there is a certificate with a CN of http://www.edugain.org, but a subjectAltName:dNSName of pki.edugain.org. Certificate validation should succeed in this case, but fails with wget:
haldir:~ # wget https://pki.edugain.org/edugainca/crl/cacrl.pem -O edugainca.crl.pem
--14:24:16-- https://pki.edugain.org/edugainca/crl/cacrl.pem
=> `edugainca.crl.pem'
Resolving pki.edugain.org... 130.206.1.23
Connecting to pki.edugain.org|130.206.1.23|:443... connected.
ERROR: certificate common name `www.edugain.org' doesn't match requested host name `pki.edugain.org'.
To connect to pki.edugain.org insecurely, use `--no-check-certificate'.
Unable to establish SSL connection.
To properly reproduce, the CyberTrust root CA and CyberTrust educational CA need to be in the browser store. You can get them from the CyberTrust website at
http://secure.globalsign.net/cacert/CT_Root_CA.pem
http://secure.globalsign.net/cacert/sureserverEDU.pem
|