Problem with openssl and verify CAfile


#1

Why I have an error?

# git clone https://github.com/letsencrypt/letsencrypt
# cd letsencrypt
# ./letsencrypt-auto certonly --standalone -d example.com -d www.example.com --debug
Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/example.com/fullchain.pem. ...
# wget https://letsencrypt.org/certs/isrgrootx1.pem -O ca.crt
# cat /etc/letsencrypt/live/example.com/fullchain.pem >> ca.crt
# openssl verify -CAfile ca.crt /etc/letsencrypt/live/example.com/cert.pem
cert.pem: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X1
error 2 at 1 depth lookup:unable to get issuer certificate

#2

With root X3 (https://www.identrust.com/certificates/trustid/root-download-x3.html) works fine:

rm -f ca.crt
wget http://pastebin.com/raw.php?i=z7SP4pb9 -O ca.crt
printf "\n" >> ca.crt
cat /etc/letsencrypt/live/example.com/chain.pem >> ca.crt
openssl verify -CAfile ca.crt /etc/letsencrypt/live/example.com/cert.pem
cert.pem: OK

#3

I believe -CAfile overrides the trusted certificate store. This means it won’t look at the default CA store. Try validating against fullchain.pem without forcing a specific CA file. If that doesn’t work, point the CAfile parameter to the system’s CA store.


#4

Hello @whk102,

You are having those issues because the Intermediate CA which signed your cert is cross-signed by IdenTrust (DST Root CA X3) and not by ISRG Root X1. When ISRG Root X1 could be included in the vast majority of certificate stores (S.O., browsers, etc.) Let’s Encrypt will sign the certificates with the Intermediate CA which is signed by ISRG Root X1 instead of DST Root CA X3.

You have all this info here.

Our intermediate is signed by ISRG Root X1. However, since we are a very new
certificate authority, ISRG Root X1 is not yet trusted in most browsers. In
order to be broadly trusted right away, our intermediate is also cross-signed by
another certificate authority, IdenTrust, whose root is already trusted in all
major browsers. Specifically, IdenTrust has cross-signed our intermediate using their
DST Root CA X3

Cheers,
sahsanu


#5

but how can one cert have two signatures at the same time?

if that would be possible I’d love a cert that is signed by startssl, LE and CACert.


#6

The certs don’t have two signatures at the same time (in the same cert). You have a cert signed by an Intermediate CA Let’s Encrypt Authority X1 (signed by IdenTrust) or you have a cert signed by an Intermediate CA Let’s Encrypt Authority X1 (signed by ISRG).


#7

okay, that’s an intresting fact so essentially the ISRG root does pretty much nothing as long as the cross sig is in place because that’s what is used, but wont ppl have to get new certs when the cross runs out, I mean it is a different intermediate.

oh my god that will be “fun”…


#8

I’m pretty sure Let’s Encrypt has already plans for a smooth transition :wink:


#9

well I doubt that (at least for now), the implementation still is very issued, like the official client runs only on linux, the server integration for apache only on debian, and the client requires root regardless of mode.
not to mention that it probably has enough dependencies and le-auto takes minutes to start before and after entering root-pw (at least on my raspi)
that gives a lot of doubt to server owners, especially because this thing updates its envoronment by itself which might cause unseen issues.

but the cross sign still has some years, unless browsers decide to distrust them (Mozilla got a bug for that, which is marked as invalid, for now, but if they dont give their full audit by like 20:22 UTC they might get in serious trouble) so unless something really bad happens they should have enough time to work on that.


#10

The certificate chain is automatically provided by an "up" link in the certificate response. I guess LE will just send their own intermediate later, so nobody will have to upgrade anything. Automation solves all these issues even for intermediates. :wink:


#11

Yes, I suppose both Intermediate CAs coexist in time to make the transition. Regarding the Mozilla issue, I saw your post and I’m waiting for any Let’s Encrypt member staff could shed some light on this audit issue


#12

There shouldn’t be any transition problems as both certificates(ISRG-signed & cross-signed) have the same public key to validate the signatures on the end-entity certificates, so all server owners would need to do would be to deliver a different intermediate certificate.


#13

well when you CAN automate it.
Windows has nothing except for IIS and caddy.


#14

You might also be able to run my PHP client on Windows as well as other clients. The client list is pretty long already.


#15

so for the sig only the key is important?
well quite nice. resolves issues if you need a different intermedia tbecause of a rename or whatever.

well I dont thnk I want a website being completely responsible for my keys and certs and I dont think that your average webserver has write access to the cert location, and not even read access if privilege dropping is in there.