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[0]. It refused to match "www*.host.com" against
> "www1.host.com".

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
> WINS.

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
shown.

-- 
      Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
       Dedicated custom curl help for hire: http://haxx.se/curl.html