# Problem with openssl and verify CAfile

**URL:** <https://community.letsencrypt.org/t/problem-with-openssl-and-verify-cafile/6057>\
**Category:** Server\
**Created:** [December 7, 2015, 3:33am UTC](https://community.letsencrypt.org/t/problem-with-openssl-and-verify-cafile/6057 "2015-12-07T03:33:33Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![whk102](https://avatars.discourse-cdn.com/v4/letter/w/c67d28/32.png) [@whk102](https://community.letsencrypt.org/u/whk102)\
**Post date:** [December 7, 2015, 3:33am UTC](https://community.letsencrypt.org/t/problem-with-openssl-and-verify-cafile/6057/1 "2015-12-07T03:33:33Z")

</div>

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
```

---

<div class="post-metadata">

**Author:** ![whk102](https://avatars.discourse-cdn.com/v4/letter/w/c67d28/32.png) [@whk102](https://community.letsencrypt.org/u/whk102)\
**Post date:** [December 7, 2015, 3:51am UTC](https://community.letsencrypt.org/t/problem-with-openssl-and-verify-cafile/6057/2 "2015-12-07T03:51:54Z")

</div>

With root X3 ([https://www.identrust.com/certificates/trustid/root-download-x3.html](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
```

---

<div class="post-metadata">

**Author:** ![motoko](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/motoko/32/26328_2.png) [@motoko](https://community.letsencrypt.org/u/motoko)\
**Post date:** [December 7, 2015, 6:12am UTC](https://community.letsencrypt.org/t/problem-with-openssl-and-verify-cafile/6057/3 "2015-12-07T06:12:44Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![sahsanu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/sahsanu/32/89984_2.png) [@sahsanu](https://community.letsencrypt.org/u/sahsanu)\
**Post date:** [December 7, 2015, 12:00pm UTC](https://community.letsencrypt.org/t/problem-with-openssl-and-verify-cafile/6057/4 "2015-12-07T12:00:05Z")

</div>

> [@whk102](#):
>
> Why I have an error?

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](https://letsencrypt.org/certificates/).

> 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

---

<div class="post-metadata">

**Author:** ![My1](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/my1/32/1013_2.png) [@My1](https://community.letsencrypt.org/u/My1)\
**Post date:** [December 7, 2015, 12:02pm UTC](https://community.letsencrypt.org/t/problem-with-openssl-and-verify-cafile/6057/5 "2015-12-07T12:02:51Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![sahsanu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/sahsanu/32/89984_2.png) [@sahsanu](https://community.letsencrypt.org/u/sahsanu)\
**Post date:** [December 7, 2015, 12:14pm UTC](https://community.letsencrypt.org/t/problem-with-openssl-and-verify-cafile/6057/6 "2015-12-07T12:14:09Z")

</div>

> [@My1](#):
>
> but how can one cert have two signatures at the same time?

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

---

<div class="post-metadata">

**Author:** ![My1](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/my1/32/1013_2.png) [@My1](https://community.letsencrypt.org/u/My1)\
**Post date:** [December 7, 2015, 12:15pm UTC](https://community.letsencrypt.org/t/problem-with-openssl-and-verify-cafile/6057/7 "2015-12-07T12:15:46Z")

</div>

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”…

---

<div class="post-metadata">

**Author:** ![sahsanu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/sahsanu/32/89984_2.png) [@sahsanu](https://community.letsencrypt.org/u/sahsanu)\
**Post date:** [December 7, 2015, 12:17pm UTC](https://community.letsencrypt.org/t/problem-with-openssl-and-verify-cafile/6057/8 "2015-12-07T12:17:31Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![My1](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/my1/32/1013_2.png) [@My1](https://community.letsencrypt.org/u/My1)\
**Post date:** [December 7, 2015, 12:22pm UTC](https://community.letsencrypt.org/t/problem-with-openssl-and-verify-cafile/6057/9 "2015-12-07T12:22:17Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![kelunik](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/kelunik/32/359_2.png) [@kelunik](https://community.letsencrypt.org/u/kelunik)\
**Post date:** [December 7, 2015, 12:29pm UTC](https://community.letsencrypt.org/t/problem-with-openssl-and-verify-cafile/6057/10 "2015-12-07T12:29:41Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![sahsanu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/sahsanu/32/89984_2.png) [@sahsanu](https://community.letsencrypt.org/u/sahsanu)\
**Post date:** [December 7, 2015, 12:30pm UTC](https://community.letsencrypt.org/t/problem-with-openssl-and-verify-cafile/6057/11 "2015-12-07T12:30:27Z")

</div>

> [@My1](#):
>
> 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.

Yes, I suppose both Intermediate CAs coexist in time to make the transition. Regarding the Mozilla issue, I saw your [post](https://community.letsencrypt.org/t/audit-and-problems-with-mozilla/6118) and I'm waiting for any Let's Encrypt member staff could shed some light on this audit issue

---

<div class="post-metadata">

**Author:** ![autoit4you](https://avatars.discourse-cdn.com/v4/letter/a/eada6e/32.png) [@autoit4you](https://community.letsencrypt.org/u/autoit4you)\
**Post date:** [December 7, 2015, 12:31pm UTC](https://community.letsencrypt.org/t/problem-with-openssl-and-verify-cafile/6057/12 "2015-12-07T12:31:23Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![My1](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/my1/32/1013_2.png) [@My1](https://community.letsencrypt.org/u/My1)\
**Post date:** [December 7, 2015, 12:31pm UTC](https://community.letsencrypt.org/t/problem-with-openssl-and-verify-cafile/6057/13 "2015-12-07T12:31:34Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![kelunik](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/kelunik/32/359_2.png) [@kelunik](https://community.letsencrypt.org/u/kelunik)\
**Post date:** [December 7, 2015, 12:32pm UTC](https://community.letsencrypt.org/t/problem-with-openssl-and-verify-cafile/6057/14 "2015-12-07T12:32:29Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![My1](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/my1/32/1013_2.png) [@My1](https://community.letsencrypt.org/u/My1)\
**Post date:** [December 7, 2015, 12:32pm UTC](https://community.letsencrypt.org/t/problem-with-openssl-and-verify-cafile/6057/15 "2015-12-07T12:32:38Z")

</div>

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.
