curl-users
Re: for wildcard certificates, different platforms behaving differently
Date: Wed, 11 May 2016 19:58:34 +0100
On 11 May 2016, at 16:44, Rick Berge <rberge_at_vectorworks.net> wrote:
> I’m using libcurl to connect to a site x.y.foo.net that has a wildcard certificate for *.foo.net.
>
> On a Win8.1 PC with libcurl identifying itself as version "7.45.0", ssl_version "OpenSSL/1.0.1p" I see
> curl: Info: Server certificate:
> curl: Info: subject: OU=Domain Control Validated; CN=*.foo.net
> curl: Info: subjectAltName does not match x.y.foo.net
> curl: Info: SSL: no alternative certificate subject name matches target host name 'x.y.foo.net'
>
> Ok, that’s about what I’d expect. * should only match a single hostname/domain-name component.
>
> On a 10.11 Mac with version "7.43.0", ssl_version "SecureTransport" it just quietly, successfully connects. Since this is my primary environment, I didn’t even realize there was a certificate problem.
>
> From what I can tell, I don’t see any bugs reported on this. Should there be? And do the other vtls adapters need checking too?
To put this another way:
RFC 2818 s3.1 says:
Matching is performed using the matching rules specified by RFC2459.
If more than one identity of a given type is present in
the certificate (e.g., more than one dNSName name, a match in any one
of the set is considered acceptable.) Names may contain the wildcard
character * which is considered to match any single domain name
component or component fragment. E.g., *.a.com matches foo.a.com but
not bar.foo.a.com. f*.com matches foo.com but not bar.com.
With OS-X 'SecureTransport', *.a.com is matching bar.foo.a.com when it
ought not. On Windows with OpenSSL there is no problem.
Is that correct? If so, that would appear to be a bug. I'm sure a full
'curl --version' from OS-X would help.
-- Alex Bligh ------------------------------------------------------------------- List admin: https://cool.haxx.se/list/listinfo/curl-users FAQ: https://curl.haxx.se/docs/faq.html Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2016-05-11