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 versus those of 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.
Did you configure your server to send the intermediate cert?
My Apache config look like:
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 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) , 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!
@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
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
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!).
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!
@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?
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
No, that was exactly the issue! My config used only
SSLCertificateKeyFile, but didn't have the requisite
SSLCertificateChainFile directive. Adding that and restarting resolved that immediately.
Thanks for the quick replies everyone!
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:
The above does not work for me! But with the use of an intermediate chain certificate it works like a charm!
Only as I understand Schoen correctly this is not how it should be…
@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.
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:
…should not work under Apache 2.4. But these lines do work perfectly.
As a matter of fact:
… does NOT work under Apache 2.4.
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
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!
Hi @Anthon, did you check your site with https://www.ssllabs.com/ssltest/? They’ll let you know whether or not there is a certificate chain problem on the site.
@Anthon I had exactly the same problem. In my case, the issue was that I had configured default
/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.
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!
@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.
I appreciate the clarification.
Received “B” after running 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?
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
The test was run 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
Which stated the “intermediate” certificate was in the file chain.pem.
(2) Also helpful was https://www.ssllabs.com/ssltest/ which gives a plethora of seemingly encrypted information to decipher.
(3) Apache 2.4 virtual host configuration
<VirturalHost *:443 > (or what ever)
SSLCertificateChainFile …/chain.pem (the intermediate cert)