Add ssl.CERT_REQUIRED_NO_VERIFY as possible value for ssl.SSLContext.verify_mode

[bafa8713-65e4-4e36-862a-61b044d41b2e]

BPO	46779
Nosy	@tiran, @freundTech

^{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: ```python assignee = 'https://github.com/tiran' closed_at = None created_at = labels = ['expert-SSL', 'type-feature', '3.11'] title = 'Add ssl.CERT_REQUIRED_NO_VERIFY as possible value for ssl.SSLContext.verify_mode' updated_at = user = 'https://github.com/freundTech' ``` bugs.python.org fields: ```python activity = actor = 'freundTech' assignee = 'christian.heimes' closed = False closed_date = None closer = None components = ['SSL'] creation = creator = 'freundTech' dependencies = [] files = [] hgrepos = [] issue_num = 46779 keywords = [] message_count = 1.0 messages = ['413416'] nosy_count = 2.0 nosy_names = ['christian.heimes', 'freundTech'] pr_nums = [] priority = 'normal' resolution = None stage = None status = 'open' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue46779' versions = ['Python 3.11'] ```

[bafa8713-65e4-4e36-862a-61b044d41b2e]

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.