Better TLS error messages

[blyxxyz]

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: CertNotValidForName

Caused 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.

[ducaale]

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