Repository navigation
Add SSLContext.set_verify_callback() #75425
Description
| BPO | 31242 |
|---|---|
| Nosy | @tiran, @MineRobber9000, @freundTech |
| PRs | |
| Superseder |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2017-08-20.21:49:16.457>
labels = ['expert-SSL', 'type-feature', '3.11']
title = 'Add SSLContext.set_verify_callback()'
updated_at = <Date 2022-02-17.18:10:47.270>
user = 'https://bugs.python.org/rfinnie'bugs.python.org fields:
activity = <Date 2022-02-17.18:10:47.270>
actor = 'christian.heimes'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['SSL']
creation = <Date 2017-08-20.21:49:16.457>
creator = 'rfinnie'
dependencies = []
files = []
hgrepos = []
issue_num = 31242
keywords = ['patch']
message_count = 5.0
messages = ['300607', '359268', '413417', '413422', '413424']
nosy_count = 6.0
nosy_names = ['christian.heimes', 'rfinnie', 'David Peall', 'kwatsen', 'MineRobber9000', 'freundTech']
pr_nums = ['31391']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = '28747'
type = 'enhancement'
url = 'https://bugs.python.org/issue31242'
versions = ['Python 3.11']
Activity
rfinnie commentedon Aug 20, 2017
At the moment, SSLContext.verify_mode() allows for three modes when dealing with Purpose.CLIENT_AUTH / server_side=True:
There is currently no way to request a client certificate and manually verify it (or ignore it) if it doesn't pass OpenSSL verification. OpenSSL provides SSL_CTX_set_cert_verify_callback for using a custom callback[0], but this is not exposed in Python.
It would be nice to have a set_verify_callback() method, similar to how set_servername_callback() does it for SSL_CTX_set_tlsext_servername_callback.
[0] https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_verify.html
kwatsen commentedon Jan 4, 2020
Very much needing this!
My situation is a mutli-tenant asynchio-based server whereby each tenant is able to configure other clients that can connect. The current strategy requires all certs to be known up-front that, for now, necessitates a painful restart whenever new auth for a client-certificate is configured.
freundTech commentedon Feb 17, 2022
I also need this feature for something I'm working on, so I looked into it a bit and pushed a small proof of concept implementation to GitHub (See PR 31391).
I'm not sure if I'll have enough time to finish and clean up this implementation, but at least there is a starting point.
I also opened bpo-46779 as a simpler method to solve most of the usecases that would be solved by this api.
tiran commentedon Feb 17, 2022
Unfortunately a generic and future-proof verify callback is much more work. We need to expose and wrap X509_STORE_CTX, X509_STORE, X509 (include STACK_OF(X509)), and probably several other OpenSSL structures. We also need to expose error codes.
tiran commentedon Feb 17, 2022
bpo-28747 was an older ticket for implementing a callback.
RobBotic1 commentedon Feb 20, 2025
I need a feature like this as well. Ideally, one could specify whether the callback replaces the verification done by OpenSSL or is in addition to it.
For myself, I need to add a handful of certificate verification checks during the TLS handshake such as checking some of the policy values. I know of no other way this could be done.
I'd also note that PyOpenSSL has this functionality (https://github.com/pyca/pyopenssl/blob/9b8c497e91ae5c50cfaf27a591698d547eee9c1d/src/OpenSSL/SSL.py#L1325 and https://github.com/pyca/pyopenssl/blob/9b8c497e91ae5c50cfaf27a591698d547eee9c1d/src/OpenSSL/SSL.py#L2035) and it is one of the reasons cited for continued use of PyOpenSSL instead of the native ssl module. Unfortunately, there are many scenarios, such as asyncio, where using PyOpenSSL is not an option.