Root certificate not trusted

Help
#1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:eiuf.app

I ran this command: certbot certificates

It produced this output:
Found the following certs:
Certificate Name: eiuf.app-0001
Serial Number: 4cb137e1bbeee630c3a416137ac5cef57cb
Domains: eiuf.app
Expiry Date: 2021-02-07 16:04:38+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/eiuf.app-0001/fullchain.pem
Private Key Path: /etc/letsencrypt/live/eiuf.app-0001/privkey.pem
Certificate Name: eiuf.app
Serial Number: 4b8d5ecd742b29da3b22e6b53b4e83aa51c
Domains: eiuf.app www.eiuf.app
Expiry Date: 2021-02-07 16:12:31+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/eiuf.app/fullchain.pem
Private Key Path: /etc/letsencrypt/live/eiuf.app/privkey.pem

My web server is (include version):Apache

The operating system my web server runs on is (include version):
CentOS 8

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):certbot 1.9

eiuf.app-le-ssl.conf:

<VirtualHost *:433>
ServerName www.eiuf.app
Redirect 301 / https://eiuf.app/

<VirtualHost *:443>
    ServerName eiuf.app
    ServerAlias eiuf.app
    DocumentRoot /var/www/eiuf.app/html/public
    ErrorLog /var/www/eiuf.app/log/error.log
    CustomLog /var/www/eiuf.app/log/requests.log combined

    <Directory /var/www/eiuf.app/html>
        AllowOverride All
    </Directory>

Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/eiuf.app/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/eiuf.app/privkey.pem
</VirtualHost>
</IfModule>

When i check the www certificate it works fine but when i try to use the non www certificate it says not trusted.

#2

Probably because you haven't got any certificate configured in your www VirtualHost.

Hm, weird, I'm getting a self signed certificate for both hostnames..

What's the output of apachectl -S?

2 Likes
#3

I tried it and get nothing back

[root@EIUF ~]# apachectl -S
[root@EIUF ~]#

#4

That's very weird.. Could be a CentOS thing.. Could you try /sbin/httpd -S?

1 Like
#5

That did work:

[Mon Nov 09 18:16:37.090671 2020] [so:warn] [pid 150349:tid 140239128443200] AH01574: module wsgi_module is already loaded, skipping
VirtualHost configuration:
*:433 www.eiuf.app (/etc/httpd/sites-enabled/eiuf.app-le-ssl.conf:2)
*:443 is a NameVirtualHost
default server eiuf.app (/etc/httpd/conf.d/ssl.conf:40)
port 443 namevhost eiuf.app (/etc/httpd/conf.d/ssl.conf:40)
port 443 namevhost eiuf.app (/etc/httpd/sites-enabled/eiuf.app-le-ssl.conf:12)
alias eiuf.app
*:80 is a NameVirtualHost
default server www.eiuf.app (/etc/httpd/sites-enabled/eiuf.app.conf:1)
port 80 namevhost www.eiuf.app (/etc/httpd/sites-enabled/eiuf.app.conf:1)
port 80 namevhost eiuf.app (/etc/httpd/sites-enabled/eiuf.app.conf:10)
ServerRoot: "/etc/httpd"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/etc/httpd/logs/error_log"
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex authdigest-client: using_defaults
Mutex lua-ivm-shm: using_defaults
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex authn-socache: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/etc/httpd/run/" mechanism=default
Mutex cache-socache: using_defaults
Mutex authdigest-opaque: using_defaults
Mutex watchdog-callback: using_defaults
Mutex proxy-balancer-shm: using_defaults
PidFile: "/etc/httpd/run/httpd.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="apache" id=48
Group: name="apache" id=48

#6

Here's (part) of your problem: your hostname is configured in two configuration files. The ssl.conf probably has preference, but without the correct certificates used.

The other part which I already pointed out in a previous post is the lack of certificate configuration for your www subdomain to base domain redirect on port 443.

2 Likes
#7

Thanks i just removed the ssl.conf and now everything is working fine.

2 Likes
#8

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