I realize the openssl s_client tool tries to be upper-layer protocol agnostic, but doesn’t everything that uses SSL do commonName checking (HTTP, SMTP, IMAP, FTP, POP, XMPP)? Shouldn’t this be something openssl s_client does by default, maybe with an option to turn it off for less common situations?
Here it doesn’t complain about connecting to “outflux.net” when the cert has a CN for “www.outflux.net”:
echo QUIT | openssl s_client -CApath /etc/ssl/certs \ -connect outflux.net:443 2>/dev/null | egrep "subject=|Verify"
subject=/CN=www.outflux.net
Verify return code: 0 (ok)
© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
I use gnutls-cli for this exact reason:
$ gnutls-cli -p 443 outflux.net
Resolving ‘outflux.net’…
Connecting to ‘198.145.64.173:443’…
– Ephemeral Diffie-Hellman parameters
– Using prime: 1024 bits
– Secret key: 1022 bits
– Peer’s public key: 1024 bits
– Certificate type: X.509
– Got a certificate list of 1 certificates.
– Certificate[0] info:
– subject `CN=www.outflux.net’, issuer `O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support@cacert.org’, RSA key 2048 bits, signed using RSA-SHA, activated `2010-01-04 17:17:30 UTC’, expires `2010-07-03 17:17:30 UTC’, SHA-1 fingerprint `1cba7d1559705ac6b461cff4a24d1d73a391804b’
– The hostname in the certificate does NOT match ‘outflux.net’
Comment by Vincent Bernat — March 11, 2010 @ 3:15 am
Well, it’s not really protocol related. The RFC doesn’t require such control, and since OpenSSL is an implementation of the RFC…
Comment by Julien — March 11, 2010 @ 4:17 am
FWIW, at least for XMPP that would not be correct behaviour. The RFC explicitly states:
“A server’s domainpart SHOULD NOT be represented as a Common Name;
instead, the Common Name field SHOULD be reserved for representation
of a human-friendly name.”
Comment by Florob — March 11, 2010 @ 5:14 am