This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author kiilerix
Recipients Ryan.Tucker, ahasenack, asdfasdfasdfasdfasdfasdfasdf, debatem1, devin, giampaolo.rodola, heikki, janssen, jsamuel, kiilerix, orsenthil, pitrou, vila, zooko
Date 2010-10-06.18:32:40
SpamBayes Score 2.73836e-11
Marked as misclassified No
Message-id <>
I'm sorry to make the discussion longer ...

From a Python user/programmers point of view it would be nice if 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.

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

Some comments to the patch. Some of them are just thoughts that can be ignored, but I think some of them are relevant.


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

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.

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 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"? 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?

"dnsnames" doesn't say much about what it is. Perhaps "unmatched"?

"if san: ... else: ..." would perhaps be a bit clearer.

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

Separate error messages for subjectAltName and commonName could be helpful.

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


cert for is defined twice.


How about unicode and/or IDN hostnames?
Date User Action Args
2010-10-06 18:32:51kiilerixsetrecipients: + kiilerix, zooko, janssen, orsenthil, pitrou, giampaolo.rodola, vila, heikki, ahasenack, debatem1, jsamuel, devin, asdfasdfasdfasdfasdfasdfasdf, Ryan.Tucker
2010-10-06 18:32:51kiilerixsetmessageid: <>
2010-10-06 18:32:49kiilerixlinkissue1589 messages
2010-10-06 18:32:47kiilerixcreate