> From a Python user/programmers point of view it would be nice if
> http://docs.python.org/library/ssl.html also clarified what
> "validation" means (apparently that the cert chain all the way from
> one of ca_certs is valid and with valid dates, except that CRLs not
> are checked?). It could perhaps be mentioned next to the ca_certs
> description. It would also be nice to see an example with
> subjectAltName, both with DNS and IP entries.

As mentioned in the patch, IP entries are not supported.
I'm planning to do a couple of doc updates as part of the commit, but
any doc suggestions should go in a separate issue IMO. This will make
things more manageable.

> Has it been tested that the way Python uses OpenSSL really checks both
> notBefore and notAfter?

I just checked and, yes, it does (but only if you specify CERT_OPTIONAL
or CERT_REQUIRED, of course).

> AFAICS * shouldn't match the empty string. I would expect "fail(cert,
> '.a.com')".

Good point.

> I would prefer to fail to the safe side and only allow a left-most
> wildcard and thus not allow multiple or f* wildcards, just like
> draft-saintandre-tls-server-id-check-09 suggests.

Well, RFC 2818 allows them, and I see no point in being stricter.

> I would prefer to not use re for such an important task where clarity
> and correctness is so important. If we only allow left-most wildcards
> it shouldn't be necessary.

I'm not convinced that manual parsing is really more readable than
regular expressions, and wildcards are a pretty obvious use case for
regular expressions. Perhaps it's a matter of habit.

> match_hostname:
> 
> I don't understand "IP addresses are not accepted for hostname". I
> assume that if commonName specifies an IP address then a hostname with
> this address is valid. So isn't it more that "subjectAltName iPAddress
> isn't supported"?

Indeed. But, strictly speaking, there are no tests for IPs, so it
shouldn't be taken for granted that it works, even for commonName.
The rationale is that there isn't really any point in using an IP rather
a host name.

> But wouldn't it be better and simpler to simply support iPAddress -
> either as the only check iff hostname "looks" like an IP address,
> alternatively in all cases check against both DNS and IP entries?

Well, that's additional logic to code. I'm not sure it's worth it,
especially given that the function is called match_hostname in the first
place.

> "doesn't match with either of (%s)" ... isn't the paranthesis around
> the list elements too pythonic for a message intended for end users?

Hmm, perhaps.

> Separate error messages for subjectAltName and commonName could be
> helpful.

That depends if you're an end user or an SSL expert, I guess. end users
don't know what subjectAltNames and commonNames are.

> I assume it should be "no appropriate _commonName_" to match
> "subjectAltName".

Ah, yes.

> cert for example.com is defined twice.

Right.

> How about unicode and/or IDN hostnames?

I haven't looked how these work in the context of certificate checking.
I would prefer to tackle that separately if needed, but someone can
provide a patch for this if they want.