On gio, set 04, 2014 at 08:51:35 -0400, Jason wrote: > Package: curl > Version: 7.26.0-1+wheezy9 > > Curl fails to validate SSL certificates with asterisks in their CN or > subAltName. This works: > > $ curl -vv -o - https://blah.s3.amazonaws.com > > * About to connect() to blah.s3.amazonaws.com port 443 (#0) > * Trying 205.251.243.81... > * connected > [snip] > * Server certificate: > * subject: C=US; ST=Washington; L=Seattle; O=Amazon.com Inc.; > CN=*.s3.amazonaws.com > * start date: 2014-04-09 00:00:00 GMT > * expire date: 2015-04-09 23:59:59 GMT > * subjectAltName: blah.s3.amazonaws.com matched > * issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of > use at https://www.verisign.com/rpa (c)10; CN=VeriSign Class 3 Secure Server > CA - G3 > * SSL certificate verify ok. > [snip] > > While this fails: > > $ curl -vv -o - https://blah.blah.s3.amazonaws.com > > * About to connect() to blah.blah.s3.amazonaws.com port 443 (#0) > * Trying 205.251.243.81... > * connected > [snip] > * Server certificate: > * subject: C=US; ST=Washington; L=Seattle; O=Amazon.com Inc.; > CN=*.s3.amazonaws.com > * start date: 2014-04-09 00:00:00 GMT > * expire date: 2015-04-09 23:59:59 GMT > * subjectAltName does not match blah.blah.s3.amazonaws.com > [snip] > > For this specific certificate, both the CN and the DNS (subjectAltName) have > the *.s3.amazonaws.com domains listed.
This is actually the correct behaviour, as per RFC6125 section 6.4.3 [0] (which curl follows). In fact, every other application I tested (wget, chromium, ...) follows this rule as well. This was introduced in curl 7.26.0 AFAICT. > The version of curl currently on Squeeze validates any of those domains > correctly. It's running curl v7.21.0-2.1+squeeze8. If anything, this is a bug in squeeze's curl, unlikely to get fixed though. Cheers [0] http://tools.ietf.org/html/rfc6125#section-6.4.3
signature.asc
Description: Digital signature
