Message150144
| Author |
pitrou |
| Recipients |
Dan.Kaminsky, naif, pitrou |
| Date |
2011年12月23日.10:22:45 |
| SpamBayes Score |
1.1762008e-10 |
| Marked as misclassified |
No |
| Message-id |
<1324635766.08.0.721676150674.issue13647@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> Be sure to support SAN. People forget that, and the API makes it a pain in
> the butt (the validator doesn't even know who you're validating for).
Right, that's why we added the match_hostname() function. It knows about subjectAltName, except for raw IP addresses.
The tests for it can be found here:
http://hg.python.org/cpython/file/0466ee1816b1/Lib/test/test_ssl.py#l265
> Technically, you could check the Windows certificate stores too, if you
> wanted to write that code.
Well, I don't know how to interface them with OpenSSL.
> Before going to python-dev, what do you think is feasible,
> implementation-wise?
Technically, shipping certificates shouldn't be difficult. The final install location is defined at "./configure" time, so loading the certs shouldn't be a problem either.
Whether or not we enable them by default is a matter of policy. I think enabling them by default could be a nasty surprise for users who currently rely on a narrower set of trusted certs.
> The right thing would be to use the in-built cert set if and only if the
> system certs couldn't be checked.
That might not be easy. OpenSSL's SSL_CTX_set_default_verify_paths() deliberately doesn't report errors. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2011年12月23日 10:22:46 | pitrou | set | recipients:
+ pitrou, naif, Dan.Kaminsky |
| 2011年12月23日 10:22:46 | pitrou | set | messageid: <1324635766.08.0.721676150674.issue13647@psf.upfronthosting.co.za> |
| 2011年12月23日 10:22:45 | pitrou | link | issue13647 messages |
| 2011年12月23日 10:22:45 | pitrou | create |
|