Better TLS error messages
blyxxyz opened this issue · comments
When a TLS certificate has the wrong hostnames it would be helpful to print which hostnames it does have.
HTTPie happens to do this, but we don't:
$ http https://wrong.host.badssl.com
http: error: SSLError: HTTPSConnectionPool(host='wrong.host.badssl.com', port=443): Max retries exceeded with url: / (Caused by SSLError(CertificateError("hostname 'wrong.host.badssl.com' doesn't match either of '*.badssl.com', 'badssl.com'"))) while doing a GET request to URL: https://wrong.host.badssl.com/
$ xh https://wrong.host.badssl.com
xh: error: error sending request for url (https://wrong.host.badssl.com/): error trying to connect: invalid peer certificate contents: invalid peer certificate: CertNotValidForNameCaused by:
0: error trying to connect: invalid peer certificate contents: invalid peer certificate: CertNotValidForName
1: invalid peer certificate contents: invalid peer certificate: CertNotValidForName$ xh --native-tls https://wrong.host.badssl.com
xh: error: error sending request for url (https://wrong.host.badssl.com/): error trying to connect: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1914: (Hostname mismatch)Caused by:
0: error trying to connect: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1914: (Hostname mismatch)
1: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1914: (Hostname mismatch)
2: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1914:
(The above --native-tls
error message is with OpenSSL on Linux, maybe Windows or macOS already includes this information.)
When a certificate is expired it's also useful to see for how long it's been expired, but that's less important. (HTTPie doesn't do this.)
I don't know how to implement this, or if we can implement it at all. It might involve library changes, and it might involve bespoke error handling in main()
. It might involve messy extraction of the certificate before we drop the reqwest client. It might be really hard.
For reference, this is how certificate errors are reported in Windows:
$ xh --native-tls https://wrong.host.badssl.com
xh: error: error sending request for url (https://wrong.host.badssl.com/): error trying to connect: The
certificate's CN name does not match the passed value. (os error -2146762481)
Caused by:
0: error trying to connect: The certificate's CN name does not match the passed value. (os error -2146762481)
1: The certificate's CN name does not match the passed value. (os error -2146762481)
I will check how the same error looks on macOS tomorrow.
Edit: Here is an example of macOS certificate error
xh --native-tls https://wrong.host.badssl.com
xh: error: error sending request for url (https://wrong.host.badssl.com/): error trying to connect: The
certificate was not trusted.
Caused by:
0: error trying to connect: The certificate was not trusted.
1: The certificate was not trusted