| msg250718 - (view) |
Author: Grant Bremer (gbremer) * |
Date: 2015-09-15 01:31 |
| The SSL_set_verify_depth OpenSSL method is not currently exposed by the ssl module. The context object would seem to be the proper place for it as an instance method. |
|
|
| msg250741 - (view) |
Author: STINNER Victor (vstinner) *  |
Date: 2015-09-15 08:43 |
| + if (depth < 0 | |
depth > 100) { Why 100 and not 10 or 1000? SSL_CTX_set_verify_depth() is unable to check the depth? The patch lacks unit tests and documentation. The patch is for Python 2.7, it would be better to write a patch for the default branch (future Python 3.6). |
|
| msg250782 - (view) |
Author: Grant Bremer (gbremer) * |
Date: 2015-09-15 16:55 |
| I had thought that I had found documentation that the max depth is 100 and anything higher is ignored -- and as I read that back to me, I believe I read an example passage and interpreted it incorrectly. I'll remove that. We primarily use Python 2.7, so I started there. I'll submit another patch with changes on the 3.5 branch and add tests. |
|
|
| msg250842 - (view) |
Author: Grant Bremer (gbremer) * |
Date: 2015-09-16 12:08 |
| Attached is a patch for the 3.5 branch. The test is minimal -- we are relying on the underlying OpenSSL library and its context to manage the data. I have removed the data validation from the set function -- OpenSSL seems happy to accept negative numbers for depth, even if that is a non-sensical value. I have started on the documentation, and can do a more comprehensive job if the code section is good or mostly good. I'll do the same for the 2.7 patch. |
|
|
| msg301478 - (view) |
Author: Christian Heimes (christian.heimes) * |
Date: 2017-09-06 15:03 |
| The patch looks fairly simple, but what is your use case? I don't like to clobber the SSLContext with additional features. I have never been in a situation that required me to change the verify depths for chain building. Why do you want to restrict or enlarge the verify depths? OpenSSL's default verify depths is sensible. |
|
|
| msg301479 - (view) |
Author: Alex Gaynor (Alex Gaynor) |
Date: 2017-09-06 15:10 |
| +1 on making sure we have a concrete use case before expanding the API |
|
|
| msg301838 - (view) |
Author: Grant Bremer (gbremer) * |
Date: 2017-09-10 22:57 |
| The use case is for an internal PKI implementation where verification should be, needs to be limited to certificates signed by the PKI CA and no higher to, say, a larger realm which would not be appropriate. |
|
|
| msg301972 - (view) |
Author: Christian Heimes (christian.heimes) * |
Date: 2017-09-12 16:17 |
| Grant, I'm not sure I follow you. Do I understand correctly that you want to call SSL_CTX_set_verify_depth(ctx, 1), in order to enforce that a peer cert is directly signed by your CA? That doesn't sound like a good use of SSL_CTX_set_verify_depth(), because it only works for a simple case without an intermediate CA. Most real-world cases have one or more intermediate CAs. |
|
|
| msg301975 - (view) |
Author: Alex Gaynor (Alex Gaynor) |
Date: 2017-09-12 16:40 |
| For the use case of "I want to trust this CA, but I don't want to trust any of it's sub CAs" I think there's a simpler solution than expanding our API: Create your own cross-sign of the root you want, and add a pathLenConstraint: 0 to the basicConstraints extension. By create a cross-sign, I mean a new certificate with the same subject/SPKI/SKI/other-extensions, but instead of being self-signed, sign it under some random private key you throw away. And then use that as your trust root, instead of the original certificate. This should work fine for validation. |
|
|
| msg312854 - (view) |
Author: Christian Heimes (christian.heimes) * |
Date: 2018-02-25 20:28 |
| Both Alex and I agree that verify depth is not the right solution to solve your problem. I'd rather not add more APIs unless they are useful for general audience. OpenSSL has a good default for verify depth. |
|
|