Re: SSL cert error
Date: Mon, 14 Jun 2004 09:17:25 +0200 (CEST)
On Sun, 13 Jun 2004, Gisle Vanem wrote:
> I saw it. I liked the needle and the haystack :).
Those names are actually from the Linux man page, I like them too since I
always tend to forget which argument is which otherwise!
> But cert_hostcheck() is still a bit too simple in the way it only allows a
> wildcard at certname. It refused to match "www*.host.com" against
I was under the impression that this limited wildcard support was somehow
mandated by an RFC, but when I try to find evidence for this I fail miserably.
This also makes be wonder if they could also contain more than one wildcard,
as in 'www*.h*xx.se' ?
Any SSL cert name knowledgeable people with some clues to offer here?
> And why must there be >1 dots in a cert-mask? Private host (with NetBIOS
> names) should be allowed. E.g. On Win32 and *nix with Samba, a
> https://host_on_lan should work since the name_on_lan gets resolved via
Again, I think this was due to some spec or standard saying so. However, I
don't know which and the source comments don't point out any. I can't find any
such requirements in RFC2818.
> I'm working on other things in ssluse.c; allthough not strickly any data
> that libcurl sees, it would be handy to see the initial SSL/TLS
> transactions. i.e. with "curl --trace". OpenSSL has some callbacks for this.
> Not sure it should be passed up using CURLINFO_DATA_x, or if we should add
> another CURLINFO_SSL_DATA_x etc.
I think the current *DATA_* should be for the data that the app sends/gets, so
I think I would prefer a CURLINFO_SSL_DATA_x for additional SSL data to get
-- Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se Dedicated custom curl help for hire: http://haxx.se/curl.htmlReceived on 2004-06-14