Browsers say I am the certificate issuer so it is not trusted

I installed Let’s Encrypt on a new CentOS 7.2 VPS. The “Let’s Encrypt” auto install process on Apache showed no error so everything went okay. But when I try to access to my website the browsers throw an ERR_CERT_AUTHORITY_INVALID error.

Also www.ssllabs.com shows me a T as Overall Rating. It says that I am the issuer (?).

The domain is correct and I am using the letsencrypt production server, not the staging one.

CentOS’ official repository installed the 2.4.6 Apache version so I am using this certificates configuration:

SSLCertificateKeyFile /etc/letsencrypt/live/MYDOMAIN.com/privkey.pem
SSLCertificateFile /etc/letsencrypt/live/MYDOMAIN.com/cert.pem
SSLCertificateChainFile /etc/letsencrypt/live/MYDOMAIN.com/chain.pem

BTW wget fails too:

$ wget https://MYDOMAIN.com/index.html
--2016-03-16 13:10:14--  https://MYDOMAIN.com/
Resolving MYDOMAIN.com (MYDOMAIN.com)... MYVPSIP
Connecting to MYDOMAIN.com (MYDOMAIN.com)|MYVPSIP|:443... connected.
ERROR: cannot verify MYDOMAIN.com's certificate, issued by 'emailAddress=root@MYDOMAIN.com,CN=MYDOMAIN.com,OU=SomeOrganizationalUnit,O=SomeOrganization,L=SomeCity,ST=SomeState,C=--':
  Unable to locally verify the issuer's authority.
To connect to MYDOMAIN.com insecurely, use `--no-check-certificate'.
$ 

I tried three times but don’t want to try again because of the limits. PLEASE, what can I do?
Thanks in advance.

Sorry for my poor English.

if your domain isnt too confidential could we get it so we can check this directly?

Sure.

jopilo.com

Thanks for replying.

Your configuration looks to be using a self signed cert - not the one provided my Let’s Encrypt.

Have you reloaded apache2 since configuring it ?

1 Like

did you restart your server?
the certificate says that it was issued not by LE.
many servers require a restart to load the new cert.

@serverco seems you ninja’d me.

2 Likes

I didn’t generate a self signed certificate.
I have reloaded apache so many times.

okay that’s really weird. can you check the access permissions to the certificate and key folders?
if the server daemon cannot access the certs AND KEY, it wont help much.

https://sslanalyzer.comodoca.com/?url=jopilo.com
on a side note:
also this little test (btw comodo runs a lot faster than ssltest) shows that you also have SSL3 and RC4 enabled, both are bad, better kill them.

I think you are right!

CentOS has SELinux policies enabled so it should be the reason… It doesn’t allow apache to access /etc/letsencrypt folder. Let me try disabling SELinux.

or maybe try to give the apache daemon permissions.
SELinux can be helpful for security

$ sudo setenforce 0
   setenforce: SELinux is disabled
$ sudo getsebool 
   getsebool:  SELinux is disabled
$ sudo systemctl restart httpd.service

It didn’t work. I had no luck.

what does the command
apachectl -t
give ?
also, are there any errors in the apache error log ?

apachectl -t
Syntax OK

Apache ssl logs show errors like this one
AH02042: rejecting client initiated renegotiation

/etc/letsencrypt/live and /etc/letsencrypt/archive directories had 700 perms so I did:

sudo chmod 755  /etc/letsencrypt/archive
sudo chmod 755  /etc/letsencrypt/live

I also did:

sudo chown -R apache:apache /etc/letsencrypt

Still no luck.

I just copied the keyfiles to /etc/httpd/conf.d and updated the apache config file. Now the browser shows another SSL error.

The error this time is because it is not loading the certifcates at all ( hence using http on port 443 not https )

Are there still no errors related to the certificates or config in your error logs ?

FYI

I just got a free certificate from startssl.com and it works, this is so weird. I will keep trying with Let’s Encrypt in the next weeks though.

Thank you so much for the support.

I didn't generate a self signed certificate.

Your OS likely did this for you automatically to get you up and running. On Debian I believe it uses /etc/ssl/certs/ssl-cert-snakeoil.pem by default.

/etc/letsencrypt/live and /etc/letsencrypt/archive directories had 700 perms so I did:
sudo chmod 755 /etc/letsencrypt/archive
sudo chmod 755 /etc/letsencrypt/live

No no no! Your private key is stored in there. That needs to be kept secret. They should be 700 and owned by root:root. This is what my permissions look like and I'm pretty sure they're all default:

# tree -pufig /etc/letsencrypt/
/etc/letsencrypt
[drwx------ root     root    ]  /etc/letsencrypt/accounts
[drwx------ root     root    ]  /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org
[drwx------ root     root    ]  /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory
[drwx------ root     root    ]  /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory/daa23eff1d7af15ef4afae24c8caf325
[-rw-r--r-- root     root    ]  /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory/daa23eff1d7af15ef4afae24c8caf325/meta.json
[-r-------- root     root    ]  /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory/daa23eff1d7af15ef4afae24c8caf325/private_key.json
[-rw-r--r-- root     root    ]  /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory/daa23eff1d7af15ef4afae24c8caf325/regr.json
[drwx------ root     root    ]  /etc/letsencrypt/archive
[drwxr-xr-x root     root    ]  /etc/letsencrypt/archive/example.com
[-rw-r--r-- root     root    ]  /etc/letsencrypt/archive/example.com/cert1.pem
[-rw-r--r-- root     root    ]  /etc/letsencrypt/archive/example.com/chain1.pem
[-rw-r--r-- root     root    ]  /etc/letsencrypt/archive/example.com/fullchain1.pem
[-rw-r--r-- root     root    ]  /etc/letsencrypt/archive/example.com/privkey1.pem
[drwxr-xr-x root     root    ]  /etc/letsencrypt/csr
[-rw-r--r-- root     root    ]  /etc/letsencrypt/csr/0000_csr-letsencrypt.pem
[-rw-r--r-- root     root    ]  /etc/letsencrypt/csr/0001_csr-letsencrypt.pem
[-rw-r--r-- root     root    ]  /etc/letsencrypt/csr/0002_csr-letsencrypt.pem
[drwx------ root     root    ]  /etc/letsencrypt/keys
[-rw------- root     root    ]  /etc/letsencrypt/keys/0000_key-letsencrypt.pem
[-rw------- root     root    ]  /etc/letsencrypt/keys/0001_key-letsencrypt.pem
[-rw------- root     root    ]  /etc/letsencrypt/keys/0002_key-letsencrypt.pem
[drwx------ root     root    ]  /etc/letsencrypt/live
[drwxr-xr-x root     root    ]  /etc/letsencrypt/live/example.com
[lrwxrwxrwx root     root    ]  /etc/letsencrypt/live/example.com/cert.pem -> ../../archive/example.com/cert1.pem
[lrwxrwxrwx root     root    ]  /etc/letsencrypt/live/example.com/chain.pem -> ../../archive/example.com/chain1.pem
[lrwxrwxrwx root     root    ]  /etc/letsencrypt/live/example.com/fullchain.pem -> ../../archive/example.com/fullchain1.pem
[lrwxrwxrwx root     root    ]  /etc/letsencrypt/live/example.com/privkey.pem -> ../../archive/example.com/privkey1.pem
[drwxr-xr-x root     root    ]  /etc/letsencrypt/renewal
[-rwxr-xr-x root     root    ]  /etc/letsencrypt/renewal/example.com.conf

This is just a wild guess, but the fact that the permissions of your private key are open may actually cause Apache to fail to load correctly as a safeguard. I know SSH does this if your keys have incorrect permissions.

Also, try executing the following commands (make sure it is what you have for SSLCertificateFile and SSLCertificateChainFile respectively):

# openssl x509 -in /etc/letsencrypt/live/yourdomain.com/cert.pem -text | grep Issuer

and

# openssl x509 -in /etc/letsencrypt/live/yourdomain.com/chain.pem -text | grep Issuer

You should see something like:

    Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1
            CA Issuers - URI:http://cert.int-x1.letsencrypt.org/

and

    Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
            CA Issuers - URI:http://apps.identrust.com/roots/dstrootcax3.p7c

If you see anything else you somehow managed to overwrite one or both of these files. Somehow Apache is loading the wrong certificate files, so you just need to figure out why it's doing that and correct the problem. To get an overview of your VirtualHost configuration execute apache2ctl -S and make sure you're actually editing the correct file(s).

I had the same strange issue and my case seemed really singular. There may be just 1% chance this can help you but, you can try anyway. Note: I was on versin 2.2.22

When you have mixed NameVirtualHosts like below

<NameVirtualHost your.ip.v4:443>
and somewhere else
<NameVirtualHost *:443>

The wildcard NameVirtualHost is just ignored when a client connects to your.ip.v4, but unfortunately, Apache doesn’t seem to issue any error or warning when starting.
So, look for NameVirtualHost and SSLCertificateFile anywhere in your /etc/apache2 folder, and remove any hardcoded IP in your NameVirtualHost statements, if any. Very weird (on apache2.2 though, even a namevirtualhost in /etc/apache2/sites-available/ is processed by Apache.

grep -ri 'namevirtualhost.*443' /etc/apache2/
grep -ri 'sslcertificatefile' /etc/apache2/

If that didn’t help, you could also try replacing every certificate pairs you found in previous step with your newly generated from LetsEncrypt, maybe step by step to find out which one was used by Apache;

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