SEC_ERROR_UNKNOWN_ISSUER on Ubuntu server and Apache 2.4

Server
1

I’m getting SEC_ERROR_UNKNOWN_ISSUER even on Ubuntu server and Apache 2.4 and only for Firefox, for two different servers - Debian 7 servers are OK, though client is used the exact same way on all of them.

Re-issuing doesn’t seem to help anything and i’m not exactly sure what to change?

Screenshot_2016-04-04_09-43-56_AM.jpg740×767 118 KB

I’m using the standard official Let’s encrypt client, nothing fancy just standalone cert

2

Your server is not delivering an intermediate certificate. My best guess is that your VirtualHost has a SSLCertificateFile directive pointing to a cert.pem file somewhere in /etc/letsencrypt/live/. That should be fullchain.pem instead (in the same directory).

If your setup looks any different than this, let us know how you’re calling the client (arguments and possibly cli.ini, if you’re using that) and how your VirtualHost is configured.

3

I’m not linking directly to the live folder, but copying the files to it’s own directory.

The apache config is setup the same on both Ubuntu and Debian Apache:

SSLEngine On
SSLCertificateKeyFile /etc/ssl/privkey.pem
SSLCertificateFile /etc/ssl/fullchain.pem

Command used to renew open:

/root/letsencrypt/letsencrypt-auto certonly --standalone -d domain.com --standalone-supported-challenges tls-sni-01 --renew-by-default

4

What’s the procedure you’re using to copy those files? That would be the next thing I’d check. If you’re, for example, generating your own fullchain.pem manually by concatenating chain.pem and cert.pem, and chain.pem is somehow pointing to the old intermediate certificate, this might be the result.

Can you confirm all the files in /etc/letsencrypt/live/example.com/ are still symlinks, and haven’t been replaced by actual files? I’m assuming that’s still where you’re copying the files from, even if you’re not directly linking to those files. Try:

ls -l /etc/letsencrypt/live/example.com/

… and verify all files look like this:

cert.pem -> ../../archive/example.com/cert12.pem
5

I didn’t want to run into file-lock issues due to restarts of services so i just do a simple copy:

cp /etc/letsencrypt/live/domain.com/privkey.pem  /etc/ssl/privkey.pem
cp /etc/letsencrypt/live/domain.com/fullchain.pem /etc/ssl/fullchain.pem

And fullchain.pem points to:

fullchain.pem -> ../../archive/domain.com/fullchain3.pem

6

Hm, odd - I reissued the certs on both servers, cleared Firefox caches and restarted it and now both work as expected.

This is odd since i just upgraded Firefox and then ran into the certs issue - our clients was the ones who reported it and after contacting them and asking them to do the same thing, it works for them too now.

Firefox cache issue?

7

Can you run the SSL Checker test again? If the intermediate warning disappeared, I guess things are fine now, although I really have no idea why. If the warning is still there, you might still run into this error depending on OS/Browser/cache.

8

Both Ubuntu servers still show as broken on ssl checker, the Debian servers are fine.

9

I don’t get why i works on Debian and not on Ubuntu, I’ve been scanning the config files and logs and can’t find anything different that sticks out! They are configured exactly the same.

10

I’m not too familiar with this particular SSL Checker site, to be honest. Can you try SSL Labs and confirm that one shows chain issues as well? It will also list all intermediate certificates that the server actually sends, that might give you a hint.

Some other commands you can try running:

openssl crl2pkcs7 -nocrl -certfile /etc/ssl/fullchain.pem | openssl pkcs7 -print_certs -text -noout

The output should contain this (look specifically for Let’s Encrypt Authority X3. Note that there are two Certificate: lines, the first one will be your own cert):

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0a:01:41:42:00:00:01:53:85:73:6a:0b:85:ec:a7:08
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
        Validity
            Not Before: Mar 17 16:40:46 2016 GMT
            Not After : Mar 17 16:40:46 2021 GMT
        Subject: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3

For good measure, compare this to the output of the same file in /etc/letsencrypt/live/.

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.