Some networked applications might require connecting to client with invalid certificates but still requiring the client to send a certificate.

ssl.SSLContext.verify_mode currently supports the following options:
ssl.CERT_NONE: Don't require the client to send a certificate and don't validate it if they send one anyways.
ssl.CERT_OPTIONAL: Don't require the client to send a certificate but validate it if they send one.
ssl.CERT_REQUIRED: Require the client to send a certificate and validate it.

There is currently no option for servers that want to require the client to send a certificate but don't validate it.

This would for example be needed it a server should accept clients with self-signed certificates and then store their certificates to recognize them again later.

A concrete example is the KDEConnect protocol.

An alternative solution would be bpo-31242. That would also solve this problem is a more general, but also more complicated way.

I think that the solution proposed here this issue is better for it's simplicity and also solves most usecases for bpo-31242.


Note that a ssl.CERT_REQUIRED_NO_VERIFY was already proposed in bpo-18293, but that issue was closed because it was specifically in relation to a deprecated api. The mentioned values are however also used in modern asyncio apis.