Closed volkerjaenisch closed 1 year ago
Hi @volkerjaenisch
The error message is coming from several layers below us and as a rule we don't stifle exception details.
The error message that is confusing is from the Python standard ssl
library.
Furthermore, it's confusing but not misleading. For the clarification for others who I'm certain will find this and think they have the same issue without understanding fully - the issue here is that the _
in your subdomain is not a valid domain name as _
is not allowed there. So something about your set up is very off.
The error message as I said comes from ssl
and probably more accurately from OpenSSL. This we have no good way to clarify as we don't have any more details than what we show you.
Dear Python requests people!
Please be not annoyed by this Bug report. I know it is not your bug, in fact it is no bug at all. But it is a pitfall a mile deep and myself has fallen twice. And unfortunately it pops up using your lib. So I wrote this bug report mainly as a pointer for others stumbling over the same stone in the SSL-Lib/RFC1035 and attributing an error to you.
Probably there is a way in requests to make a better user experience like testing for RFC 1035 compliance before calling the SSL-code.
To reproduce:
Given a wildcard certificate for *.dev.inqbus.de and a webserver serving the two subdomains utilizing this certificate:
Expected Result
Both commands succeed
Actual Result
The first call runs smoothly. The second calls produces the above trace. The error cause in the trace (Caused by SSLError(SSLCertVerificationError(1, "[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: Hostname mismatch, certificate is not valid for 'test_backend.dev.inqbus.de'. (_ssl.c:1123)")))
The stack trace in the not RFC 1035 case is misleading.
Reproduction Steps
Please have a look above
System Information