httpie doesn't recognize cert/CA provided by mkcert

[checketts]

I've been using mkcert to create a 'valid' SSL cert when developing locally.

mkcert installs a CA and adds it to the system and other toolchains so it is recognized automatically.

The cert is recognized by curl without problems, but httpie is failing (unless I add --verify=no)

Perhaps this is a duplicate of #480. but my hopes were that httpie might be able to support it directly (or via a --cert parameter I could pass/alias)

httpie version: 1.0.0
OS: OSX 10.14.3 Mojave

[normanr]

Does it work if you pass --verify=$(mkcert -CAROOT)/rootCA.pem? What does --debug show for the failure reason? Also try
openssl s_client -CAfile $(mkcert -CAROOT)/rootCA.pem -servername=example.com localhost:443
(look for Verify return code) or
openssl verify -auth_level 2 -CAfile $(mkcert -CAROOT)/rootCA.pem cert.pem.
I found that my self-signed CA was being rejected with CA certificate key too weak or EE certificate key too weak, so I switched to letsencrypt (for my internet facing sites).

[checketts]

Thanks! Without verify I see:

http -a user:password https://localhost.myapp.org:8443/management/prometheus

http: error: SSLError: HTTPSConnectionPool(host='localhost.myapp.org', port=8443): Max retries exceeded with url: /management/prometheus (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1056)'))) while doing GET request to URL: https://localhost.myapp.org:8443/management/prometheus

But thanks to your tip it works!

http --verify="$(mkcert --CAROOT)/rootCA.pem" -a user:password https://localhost.myapp.org:8443/management/prometheus

Note I did need to add double quotes " since on OSX the path has a space in it. Now I have an alias that includes the rootCA automatically:

alias http="http --verify=\"$(mkcert --CAROOT)/rootCA.pem\""

So I use it automatically! Thanks again!

[ye]

Does it work if you pass --verify=$(mkcert -CAROOT)/rootCA.pem? What does --debug show for the failure reason?

The --verify="$(mkcert --CAROOT)/rootCA.pem" approach doesn't work for me. As @checketts mentioned, we would need double quotes around mkcert --CAROOT to prevent globing, on macOS, there is a space in the path name. But even adding the double quotes it still doesn't work.

$ http --version
2.2.0

$ mkcert -version
v1.4.1

$ head -n 1 "$(mkcert -CAROOT)/rootCA.pem"
-----BEGIN PRIVATE KEY-----

$ http --verify="$(mkcert -CAROOT)/rootCA.pem" https://127.0.0.1:5000/api/v1/products

http: error: SSLError: HTTPSConnectionPool(host='127.0.0.1', port=5000): Max retries exceeded with url: /api/v1/products (Caused by SSLError(SSLError(136, '[X509: NO_CERTIFICATE_OR_CRL_FOUND] no certificate or crl found (_ssl.c:4232)'))) while doing a GET request to URL: https://127.0.0.1:5000/api/v1/products

And the reported X509: NO_CERTIFICATE_OR_CRL_FOUND error doesn't make sense to me as the rootCA.pem does exist, as I use head command to print out the first line.

Also try
openssl s_client -CAfile $(mkcert -CAROOT)/rootCA.pem -servername=example.com localhost:443
(look for Verify return code) or
openssl verify -auth_level 2 -CAfile $(mkcert -CAROOT)/rootCA.pem cert.pem.

These probes still doesn't work.

$ openssl s_client -CAfile "$(mkcert -CAROOT)/rootCA.pem" -servername=example.com 127.0.0.1:5000
4753356224:error:0B084088:x509 certificate routines:X509_load_cert_crl_file:no certificate or crl found:crypto/x509/by_file.c:223:

openssl s_client -CAfile "$(mkcert -CAROOT)/rootCA.pem" 127.0.0.1:5000
4718126528:error:0B084088:x509 certificate routines:X509_load_cert_crl_file:no certificate or crl found:crypto/x509/by_file.c:223:

According to this SSL/TLS troubleshooting guide

Python, Ruby, PHP, Perl... can behave in different ways, depending on language version. Even packages inside these languages might have their own rules:
They might integrate with the OpenSSL CA store. This works on UNIX, but on Windows this will mostly result in verification errors, because there is no OpenSSL CA store. To get usable Root-CAs check here.
They might come with their own CA store.

What do I miss here?

Update: I thinks #480 is related.