# \[Solved\] Why isn't my certificate trusted? **URL:** \ **Category:** Server\ **Created:** [October 30, 2015, 7:29am UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479 "2015-10-30T07:29:50Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Nightfirecat](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/nightfirecat/32/1373_2.png) [@Nightfirecat](https://community.letsencrypt.org/u/Nightfirecat)\ **Post date:** [October 30, 2015, 7:29am UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479/1 "2015-10-30T07:29:50Z")
I was recently able to use the client to create a cert and configure my Apache configurations on my Ubuntu webserver, but I’m finding that testing it against ssllabs says that I have an incomplete certificate chain, and thus have an untrusted certificate. ([my results](https://www.ssllabs.com/ssltest/analyze.html?d=nightfirec.at) versus [those of helloworld.letsencrypt.org](https://www.ssllabs.com/ssltest/analyze.html?d=helloworld.letsencrypt.org)) Do I have something misconfigured, or have I created the certificate incorrectly? I used the suggested `./letsencrypt-auto --agree-dev-preview --server https://acme-v01.api.letsencrypt.org/directory auth` to generate the cert, as well as `./letsencrypt-auto install` to create the necessary configurations. ---
**Author:** ![germeier](https://avatars.discourse-cdn.com/v4/letter/g/ba8739/32.png) [@germeier](https://community.letsencrypt.org/u/germeier)\ **Post date:** [October 30, 2015, 7:42am UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479/2 "2015-10-30T07:42:20Z")
Did you configure your server to send the intermediate cert? My Apache config look like: ``` SSLCertificateFile /etc/letsencrypt/live/$DOMAIN/cert.pem SSLCertificateKeyFile /etc/letsencrypt/live/$DOMAIN/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/$DOMAIN/chain.pem ``` ---
**Author:** ![samspin](https://avatars.discourse-cdn.com/v4/letter/s/90db22/32.png) [@samspin](https://community.letsencrypt.org/u/samspin)\ **Post date:** [October 30, 2015, 6:38pm UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479/3 "2015-10-30T18:38:54Z")
Above is correct, you need to use ‘chain.pem’ and ‘cert.pem’ separately at this time in your configuration, and NOT ‘fullchain.pem’, even though it mentions ‘fullchain.pem’ at the end of the client dialog on the command line. The difference is, the ‘chain.pem’ file contains a cross signature from an IdenTrust root which is present in most browsers today. The ‘fullchain.pem’ references the ISRG root certificate, which is not yet present in most browsers as Let’s Encrypt are still in the process of applying to have it included. Therefore you may well need to manually edit your Apache configuation file, e.g /etc/apache2/sites-available/ssl-default.conf I found I had to do this just now for [www.planetvampire.com](http://www.planetvampire.com) and it all checks out on the SSLLabs test now ([https://www.ssllabs.com/ssltest/analyze.html?d=planetvampire.com&s=2607%3a5300%3a60%3a330%3a0%3a0%3a0%3a1&latest](https://www.ssllabs.com/ssltest/analyze.html?d=planetvampire.com&s=2607%3a5300%3a60%3a330%3a0%3a0%3a0%3a1&latest)) , albeit with a warning that the second trust path is not complete (but you can ignore that as browser use the server-presented chain, if there is one). Sorry if this post sounds confusing! ---
**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\ **Post date:** [October 30, 2015, 6:45pm UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479/4 "2015-10-30T18:45:30Z")
@samspin, I don’t believe that `fullchain.pem` references the ISRG root. I originally wrote the code that originally creates it and the definition of `fullchain.pem` was `cert.pem` and `chain.pem` in a single file. The `fullchain.pem` file is intended for using in Nginx and Apache 2.4 (and other web servers that expect the end-entity certificate and certificate chain to be provided in a single file), while `chain.pem` and `cert.pem` are intended for Apache 2.2 (and other web servers that expect the end-entity certificate and certificate chain to be provided in separate files). Currently both files should be based on the same chain provided by the Let’s Encrypt CA, which would use the IdenTrust signature rather than the Let’s Encrypt root signature (if that’s changed at some point, please let me know!). ---
**Author:** ![samspin](https://avatars.discourse-cdn.com/v4/letter/s/90db22/32.png) [@samspin](https://community.letsencrypt.org/u/samspin)\ **Post date:** [October 30, 2015, 6:57pm UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479/5 "2015-10-30T18:57:42Z")
Ah, it appears Windows 10 has confused me! I’ve manually opened all these files with a text editor and you are right! You see, I wanted to check my certificate before loading it live, as Planet Vampire is a website I run for public use. It appears Windows 10 ignores the certificate chains in a bundled file and insists on trying to download the chain from the CA server instead based on the first certificate it sees. So when I downloaded ‘fullchain.pem’ via FTP and renamed it to ‘fullchain.crt’ to check it, I ended up with an error “this certificate cannot be verified up to a trusted certification authority”. But downloading ‘chain.pem’ and renaming it ‘chain.crt’ showed me the cross signed intermediate. Gosh, that’s gotta confuse others too! Might want to include a warning about this in an FAQ somewhere (even though it’s not your fault), lest someone get misled by Windows like I just did! ---
**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\ **Post date:** [October 30, 2015, 7:00pm UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479/6 "2015-10-30T19:00:59Z")
@samspin, the Windows auto-download of CAs is something that I hadn’t considered as an issue _for server admins_, but it could definitely confuse people! Do you have any proposed language for the FAQ that you think could help people better understand the implications of how Windows handles certificates? ---
**Author:** ![samspin](https://avatars.discourse-cdn.com/v4/letter/s/90db22/32.png) [@samspin](https://community.letsencrypt.org/u/samspin)\ **Post date:** [October 30, 2015, 7:20pm UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479/7 "2015-10-30T19:20:49Z")
I’m not too sure really. I suppose this is the reason Windows tends to use a different format (PFX) for distributing certificates _with their proper paths_ between machines. I thought I knew both Windows and Linux, I’ve learned something new today. As far as I can see, Windows is planned to be supported by Let’s Encrypt automation but it isn’t yet. So further down the line when it is, this might be an issue for cross-platform people like me, if for example, one wanted to use the same certificate on both a Linux machine and a Windows machine. Hopefully once your root certificate is present in most browsers, this won’t be as much an issue. The language would probably need to be shortened but the long speak of it is: When Windows encounters a certificate it cannot match up to an issuer in it’s trust store in a PEM format (commonly used with Linux), it will first check the extended properties for a download URL for the issuer. If the issuer is not in the trust store (checked via public key material), it will check the downloaded issuer’s certificate’s extended properties for _another_ download URL, and so on, until either it reaches a root in it’s trust store, if not it reports an error. _Only if_ the certificate does not include a download URL will it look further down a presented chain file for the rest of the certificate chain. In other words, it does the opposite of most modern web browsers. This is NOT the case if it encounters a certificate in a Windows PFX format, it will ALWAYS use the full chain provided in the file first. Therefore you should always use a tool on Linux to export a certificate and chain into a PFX file before attempting to use (or indeed make sense of it) on Windows. EDIT: to the original poster I am sorry for hijacking this thread, in my defense it does still relate to times where a certificate might not appear trusted, even if it has morphed into a discussion in Windows ☹ ---
**Author:** ![Nightfirecat](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/nightfirecat/32/1373_2.png) [@Nightfirecat](https://community.letsencrypt.org/u/Nightfirecat)\ **Post date:** [October 31, 2015, 1:40am UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479/8 "2015-10-31T01:40:35Z")
> [@germeier](#): > > Did you configure your server to send the intermediate cert? > > My Apache config look like: > ... No, that was exactly the issue! My config used only `SSLCertificateFile` and `SSLCertificateKeyFile`, but didn't have the requisite `SSLCertificateChainFile` directive. Adding that and restarting resolved that immediately. Thanks for the quick replies everyone! ---
**Author:** ![ametad](https://avatars.discourse-cdn.com/v4/letter/a/a87d85/32.png) [@ametad](https://community.letsencrypt.org/u/ametad)\ **Post date:** [November 9, 2015, 8:54am UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479/9 "2015-11-09T08:54:30Z")
Thanks for all the info people! But still the matter isn’t closed for me when I make use of the configuration Schoen provides. On a Ubuntu 14.04 with Apache 2.4.7 I tried: ``` SSLCertificateFile /etc/letsencrypt/live/$DOMAIN/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/$DOMAIN/privkey.pem ``` The above does not work for me! But with the use of an intermediate chain certificate it works like a charm! ``` SSLCertificateFile /etc/letsencrypt/live/$DOMAIN/cert.pem SSLCertificateKeyFile /etc/letsencrypt/live/$DOMAIN/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/$DOMAIN/chain.pem ``` Only as I understand Schoen correctly this is not how it should be… ---
**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:** [November 9, 2015, 11:17am UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479/10 "2015-11-09T11:17:56Z")
@schoen said that the one with the chain in a seperate line is for apache 2.2 for example and other who rather have it seperately, but apache 2.4 wants them in a single file so obviously the bottom one wont work. hope this helps. ---
**Author:** ![ametad](https://avatars.discourse-cdn.com/v4/letter/a/a87d85/32.png) [@ametad](https://community.letsencrypt.org/u/ametad)\ **Post date:** [November 9, 2015, 1:07pm UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479/11 "2015-11-09T13:07:09Z")
Indeed, that is what Schoen said. And it should be like that… But my point is that it is NOT like that. That? Yeah, as in: ``` SSLCertificateFile /etc/letsencrypt/live/$DOMAIN/cert.pem SSLCertificateKeyFile /etc/letsencrypt/live/$DOMAIN/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/$DOMAIN/chain.pem ``` …should not work under Apache 2.4. But these lines do work perfectly. As a matter of fact: ``` SSLCertificateFile /etc/letsencrypt/live/$DOMAIN/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/$DOMAIN/privkey.pem ``` … does NOT work under Apache 2.4. ---
**Author:** ![chriswheeler](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/chriswheeler/32/2921_2.png) [@chriswheeler](https://community.letsencrypt.org/u/chriswheeler)\ **Post date:** [December 16, 2015, 12:58pm UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479/12 "2015-12-16T12:58:18Z")
I can confirm that the following works under Apache 2.4.6 (CentOS 7) and Apache 2.2.15 (CentOS 6): `SSLCertificateFile /etc/letsencrypt/live/$DOMAIN/cert.pem SSLCertificateKeyFile /etc/letsencrypt/live/$DOMAIN/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/$DOMAIN/chain.pem` However, the following only works with some browsers on Apache 2.4.6 (fails on at least Chome on Android): `SSLCertificateFile /etc/letsencrypt/live/$DOMAIN/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/$DOMAIN/privkey.pem` ---
**Author:** ![Anthon](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/anthon/32/9876_2.png) [@Anthon](https://community.letsencrypt.org/u/Anthon)\ **Post date:** [January 18, 2017, 4:16am UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479/13 "2017-01-18T04:16:03Z")
My certificates work under Apache 2.4 (Fedora). However, they fail on Samsung Chrome and Samsung Firefox. I have tried with and without SSLCertificatChainFile /…/ chain.pem. The error message is: This Connection is Untrusted. Has this issue been resolved? Thanks! ---
**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\ **Post date:** [January 18, 2017, 8:14pm UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479/14 "2017-01-18T20:14:06Z")
Hi @Anthon, did you check your site with [https://www.ssllabs.com/ssltest/](https://www.ssllabs.com/ssltest/)? They’ll let you know whether or not there is a certificate chain problem on the site. ---
**Author:** ![rimas-kudelis](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rimas-kudelis/32/10762_2.png) [@rimas-kudelis](https://community.letsencrypt.org/u/rimas-kudelis)\ **Post date:** [January 23, 2017, 8:13am UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479/15 "2017-01-23T08:13:47Z")
@Anthon I had exactly the same problem. In my case, the issue was that I had configured default `SSLCertificateFile` and `SSLCertificateChainFile` in `/etc/apache2/mods-enabled/ssl.conf` (this cert and chain didn’t come from Let’s Encrypt), but only `SSLCertificateFile` configured for the vhost which uses Let’s Encrypt. It seems that if a default `SSLCertificateChainFile` is defined in Apache (non-vhost) config, it overrides whatever chained certificates exist in the file specified by `SSLCertificateFile` for a vhost. I fixed this issue by removing the three `SSLCertificate*` directives from `/etc/apache2/mods-enabled/ssl.conf` and instead adding them to the configs of the vhosts which used to rely on these defaults. ---
**Author:** ![Anthon](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/anthon/32/9876_2.png) [@Anthon](https://community.letsencrypt.org/u/Anthon)\ **Post date:** [January 24, 2017, 5:43am UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479/16 "2017-01-24T05:43:04Z")
@rimas-kdelis, Thanks. ssl.conf is not enabled on Ubuntu. However, applying the suggestion to Fedora by commenting out #Include /etc/httpd/conf.modules.d/00-ssl.conf in httpd.conf allowed for a secure connection on Samsung Firefox but not on Samsung Chrome. Thanks for remembering that! ---
**Author:** ![rimas-kudelis](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rimas-kudelis/32/10762_2.png) [@rimas-kudelis](https://community.letsencrypt.org/u/rimas-kudelis)\ **Post date:** [January 24, 2017, 6:49am UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479/17 "2017-01-24T06:49:13Z")
@Anthon: just to make it clear: these rules weren’t in `/etc/apache2/mods-enabled/ssl.conf` by default, I added them myself previously, which turned out to be a mistake. I don’t think avoiding the inclusion of whole ssl.conf is a good idea, it’s probably better to just comment out or remove the offending directives from it. ---
**Author:** ![Anthon](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/anthon/32/9876_2.png) [@Anthon](https://community.letsencrypt.org/u/Anthon)\ **Post date:** [January 26, 2017, 8:00pm UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479/18 "2017-01-26T20:00:12Z")
Thanks @rimas-kudelis, I appreciate the clarification. @schoen, Received “B” after running [https://www.ssllabs.com/ssltest/](https://www.ssllabs.com/ssltest/) . A plethora of output ensued. An apparent error message is: Chain issues Incomplete. Chain issues Incomplete seems to be associated with: Didn’t install the intermediate certificate. Where is the intermediate certificate? How is the intermediate certificate configured / installed? ---
**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\ **Post date:** [January 26, 2017, 10:07pm UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479/19 "2017-01-26T22:07:21Z")
Hi @Anthon, the intermediate certificate is the content of `chain.pem`, which is also included as part of `fullchain.pem`. This tells browsers that Let’s Encrypt is really a certificate authority. Some browsers already know this (generally because they previously visited some other Let’s Encrypt site and remembered the chain), and will accept the cert without the intermediate certificate. But other browsers, such as a fresh browser profile or some mobile browsers, don’t know this and need the intermediate certificate to be provided. If you’re using Apache 2.4, could you try telling it that `fullchain.pem` is your certificate file instead of `cert.pem`? ---
**Author:** ![Anthon](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/anthon/32/9876_2.png) [@Anthon](https://community.letsencrypt.org/u/Anthon)\ **Post date:** [January 26, 2017, 10:27pm UTC](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479/20 "2017-01-26T22:27:24Z")
Hi @schoen, The test was run [https://www.ssllabs.com/ssitest/](https://www.ssllabs.com/ssitest/) and an “A” was received. Marking solved! This thread was helpful (1) [This server's certificate chain is incomplete. Grade capped to B. openshift](https://community.letsencrypt.org/t/this-servers-certificate-chain-is-incomplete-grade-capped-to-b-openshift/3665/14) Which stated the “intermediate” certificate was in the file chain.pem. (2) Also helpful was [https://www.ssllabs.com/ssltest/](https://www.ssllabs.com/ssltest/) which gives a plethora of seemingly encrypted information to decipher. (3) Apache 2.4 virtual host configuration \ (or what ever) SSLCertificateFile …/cert.pem SSLCertificateKeyFile …/privkey.pem SSLCertificateChainFile …/chain.pem (the intermediate cert) [Next page](https://community.letsencrypt.org/t/solved-why-isnt-my-certificate-trusted/2479.md?page=2)