My cert is missing Root 1

My domain is: mkonferencja.pl

My operating system is: Windows 10

My web server is: CentOS 6.0 64-Bit, Apache/2.4.25

My hosting provider, if applicable, is: hitme.pl

I can login to a root shell on my machine: yes

I’m using a control panel to manage my site: DirectAdmin 1.51.3

When I try to go to my website via Chrome 57.0.2987.110 (64-bit) or Opera 43.0.2442.1144 I get an error that “This CA Root certificate is not trusted because it is not in the Trusted Root Certification Authorities store”. I have checked my site via a few SSL checkers and with all of them it works OK except this one: https://www.sslchecker.com It says that

What is wrong with my configuration then?

Not sure what web server you are using or how you configured your site but did you specify the full chain of certificates? Looks like you missed specifying the trusted_certificate

This is how an nginx config should look, not sure in your environment though.

ssl_certificate /etc/letsencrypt/live/myweb.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/myweb.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/myweb.com/chain.pem;
1 Like

It is on Apache and in Virtual Host I have this:

SSLCertificateFile /usr/local/directadmin/data/users/admin/domains/mkonferencja.pl.cert
SSLCertificateKeyFile /usr/local/directadmin/data/users/admin/domains/mkonferencja.pl.key
SSLCACertificateFile /usr/local/directadmin/data/users/admin/domains/mkonferencja.pl.cacert

I don’t use apache anymore but here’s how my Apache ssl config’s used to look, very simple example though. One thing that stands out is how I used to use SSLCertificateChainFile and you use SSLCACertificateFile. Not sure if that’s a version specific issue but this config below was from Apache 2.4 before I switched to Nginx

<IfModule mod_ssl.c>
<VirtualHost *:443>
DocumentRoot /var/www/mysite/
ServerName mysite.com
ServerAlias www.mysite.com
ErrorLog ${APACHE_LOG_DIR}/mysite-error.log
CustomLog ${APACHE_LOG_DIR}/mysite-access.log
<Directory "/var/www/mysite/">
Options +Includes
Options +FollowSymLinks -Indexes
....... OTHER STUFF HERE
</Directory>
SSLCertificateFile /etc/letsencrypt/live/mysite.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mysite.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/mysite.com/chain.pem
</VirtualHost>
</IfModule>
<VirtualHost *:80>
ServerName mysite.com
ServerAlias www.mysite.com
ErrorLog ${APACHE_LOG_DIR}/mysite-error.log
CustomLog ${APACHE_LOG_DIR}/mysite-access.log
        RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteCond %{HTTP_HOST} ^(?:www\.)?(.*)$ [NC]
        RewriteRule (.*) https://mysite.com%{REQUEST_URI} [END,QSA,R=permanent]
</VirtualHost>
1 Like

So I am missing sth called chain.pem Any idea how to generate it? I don’t see it in /usr/local/directadmin/data/users/admin/domains/ diretory where all the files are stored. I have only those files:

mkonferencja.pl.cacert
mkonferencja.pl.cert
mkonferencja.pl.cert.combined
mkonferencja.pl.cert.creation_time
mkonferencja.pl.conf
mkonferencja.pl.csr
mkonferencja.pl.cust_httpd
mkonferencja.pl.ftp
mkonferencja.pl.ip_list
mkonferencja.pl.key
mkonferencja.pl.mime.types
mkonferencja.pl.pointers
mkonferencja.pl.san_config
mkonferencja.pl.subdomains
mkonferencja.pl.usage

Can I do it with this? https://whatsmychaincert.com/

I think this is a chain problem, but it seems really weird - inconsistent? Maybe you’re changing things as I type this? My web browser sees the chain to ISRG Root X1 (which is too new to be trusted by most browsers etc. and shouldn’t be on a public web site) but an openssl command from the same machine sees the DST Root X3 chain that should be fine.

Another possibility is that you have a load-balanced setup with multiple servers and some are configured wrong?

In any case, SSLCACertificateFile is almost certainly the wrong configuration setting despite its name, SSLCertificateChainFile is more likely what you needed.

1 Like

Change your line, let me know if that changes anything.

SSLCACertificateFile /usr/local/directadmin/data/users/admin/domains/mkonferencja.pl.cacert

to

SSLCertificateChainFile /usr/local/directadmin/data/users/admin/domains/mkonferencja.pl.cacert

1 Like

The “chain” is one or more (just one for your scenario) certificates that relate your certificate (issued from Let’s Encrypt X3) to a root your browser or other software trusts (typically DST Root CA X3). Since certificates (not private keys though) are public documents, you can get the right one from anywhere, including that whatmychaincert site and it’ll be fine. Ideally you would arrange for any automation that gets you a Let’s Encrypt certificate to also update any chain too, because the chain could change, it’s not likely to change soon, but it might happen.

1 Like

Chrome … all OK

1 Like

FWIW, sslchecker.com gives the same result on my site (familybrown.org). I know I’m using the correct cert and chain files, and I haven’t had warnings from any clients. I’m not convinced it isn’t a bug on that site. FWIW, that site shows a similar result for Google.

2 Likes

Just tested 2 minutes ago …

1 Like

mkonferencja.pl is my production so I have changed SSLCACertificateFile to SSLCertificateChainFile for demo.mkonferencja.pl and have the same result. As you show it seems that everything is OK so I don’t know what problems have Chrome and Opera on Windows.

sslchecker.com shows same WRONG info for my own SSL sites. Definitely something wrong on their end, I only trust Qualsys Labs tests.

I would say their tests are simply just wrong on sslchecker.com :grinning:

1 Like

OK, to sum @tialaramex I didn’t do anything while you were checking and don’t have load balance.

@MitchellK, @tialaramex so should I change to SSLCertificateChainFile everywhere? I mean in all domains I use Let’s Encrypt on?

OK, I will ignore sslchecker.com I have already asked people on different locations, systems and web browsers and everywhere everything seems OK.
What is bothers me is that one case on Chrome and Opera (maybe because this was on Windows launched by Parallels). I also use smartsupp.com chat on my site. Recently they have added recording what people are doing on my site and I have discovered that some of them don’t have images loaded from my site. Some time ago I had this issue because not all HTTPS processes has taken new certificate settings. Some time my site was loaded with new cert and all images and sometimes without cert and images. Killing all httpd processes after rebuilding configuration helped. So I really don’t know what seems to be the problem. Maybe there is no problem at all.

Thank you for your help.

1 Like

Any complaints about root certs are an issue on their end. Every client endpoint is responsible for its own store of root certs.

3 Likes

SSLCACertificateFile is for client authentication, so unless you're issuing client certificates to your users so they can access certain parts of your website like it is described here, you shouldn't use that directive.

The SSLCertificateChainFile directive is deprecated since Apache version 2.4.8. So unless you're using an Apache older than that (i.e., 2.2 or 2.4.7 or older), you should use what is called a "bundle" file: the end user certificate as wel as the intermediate certificate in one file. The client certbot offers this bundle through the file fullchain.pem. This bundle should be used in SSLCertificateFile. Of course, for all the older Apaches you should just keep using SSLCertificateChainFile.

3 Likes

sslchecker.com seems to be pure trash. They don’t even use SNI.

Edit: Scratch that. Suddenly, they seem to use SNI. What a coincidence.

2 Likes

Ohh, so this is the case, thank you.
No, I am not serving anything for clients using Client Certificates. I see that my default configuration uses both SSLCACertificateFile and SSLCertificateFile like this:

SSLCertificateFile /usr/local/directadmin/data/users/admin/domains/mkonferencja.pl.cert

So I will stay with what I currently have.
Thank you for the knowledge.

@Osiris thanks for clearing that up. I’ve lost touch with Apache since moving to Nginx, there was just FAR too many deprecations and changes for my likings