Peer’s Certificate issuer is not recognized

The way I used to install a cert for apache webserver in the past is no longer working.


sudo dnf -y install snapd
sudo systemctl start snapd
sudo systemctl enable snapd
sudo init 6
sudo snap install core; sudo snap refresh core
sudo ln -s /var/lib/snapd/snap /snap
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
sudo dnf -y install certbot python3-certbot-apache mod_ssl
sudo nft -a list ruleset
sudo nft insert rule inet filter INPUT position 11 tcp dport {80, 443} accept
sudo systemctl restart httpd
sudo certbot --apache

Although I get "Successfully received certificate." I end up with an warning in Firefox after saying

Peer’s Certificate issuer is not recognized.
HTTP Strict Transport Security: false
HTTP Public Key Pinning: false
Certificate chain

Server version: Apache/2.4.37 (rocky)
Server built: Mar 24 2022 17:33:25

RockyLinux 4.18.0-348.20.1.el8_5.x86_64

certbot 1.22.0

I can login to a root shell on my machine (yes or no, or I don't know): yes

1 Like

Your client might not have the latest root cert store.


Is that really necessary?


Not when snap is being used. It might even pull in the non-snap-version of Certbot as a dependency, resulting in two different installations of Certbot.


Please share the hostname of the afflicted site.



Your site does not appear to be sending the Let's Encrypt certificate. Did Certbot output an installation error by any chance?

Could you please share the Apache configuration files?


This is kinda weird? Wouldn't it make more sense to put this configuration file in /sites-enabled/ to load it? Usually, Certbot handles all the stuff with this file, so maybe Certbot did it like that, but I find it kinda weird..

Not really anything strange with your configuration.. What's the output of apachectl -S ?


This one is probably the issue. Usually it's a good idea to have ssl.conf set some defaults, but it also has the same virtualhost as the ~le-ssl.conf file. You should put a different hostname in the ServerName directive of ssl.conf (e.g. or something, as long as it isn't a real website), so Apache will use the ~le-ssl.conf file for your site instead of ssl.conf.


The ssl.conf has already set an ServerName. It's commented out with # at the beginning.


Should I set the real hostname in the httpd.conf AND in the honig.conf ?

I don't know about httpd.conf, but you should NOT use the real hostname in ssl.conf, that's what I was trying to tell you. You should use the ServerName what's now commented out.


So just uncomment the fake in ssl.conf ?

Just to be clear, there is no real hostname in the ssl.conf


Or do you mean the

I did that, removed the # in /etc/httpd/conf.d/ssl.conf to use the (not sure why though), restarted httpd but still the same issue.

1 Like

Also make sure that any other ServerName directives in ssl.conf are commented out.

After that, please show the output of apachectl -S again.



which ssl.conf are you talkin' about? Because the ServerName was commented out and never used or set to the real name.?!

Please uncomment the ServerName directive, reload Apache and check again.



That's it! You solved it! :slight_smile:

Thanks for your patience. Never had to enable a fake ServerName in ssl.conf before. Will take notes for the future.

Thanks again, all the best. take care :slight_smile:



not sure if "python3-certbot-apache" is necessary. Will try next time without it.


That's because without a ServerName it'll inherit the hostname from somewhere else, in this case the actual hostname of your site. Which was double with the configuration in the ~le-ssl.conf file. But because ssl.conf was loaded earlier, it probably took precedence somehow, overruling the virtualhost in the ~le-ssl.conf file.


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