The operating system my web server runs on is (include version): Fedora 30
My hosting provider, if applicable, is: N/A
I can login to a root shell on my machine (yes or no, or I don’t know): Yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): 1.3.0
This may go back to when the server was upgraded from Fedora 29 to Fedora 30. Had to redo the certs but did not notice any issues at the time. Certbot is in the crontab to run nightly.
Most likely, the Apache configuration has “SSLCertificateFile /etc/letsencrypt/example.com/cert.pem” when it needs “SSLCertificateFile /etc/letsencrypt/example.com/fullchain.pem”.
I just checked your site, and the ssl certificate loads correctly. Maybe you already fixed it… or it could have been a caching issue.
View the site in Google Chrome or Brave. Click on the certificate information up to the left of the address bar and it should show you that it was issued by letsencrypt on 4/14/20 (that is what I see)
If that’s not what you see, try a different browser that you haven’t used to access you site with previously. If you originally created a self signed certificate, or bypassed a security warning on your site you may have to clear the browser certificate cache for it to load up the new one.
Browsers can usually -- but not always -- work around missing intermediate certificates. (By downloading them dynamically, and/or already having them cached.)
Less sophisticated TLS clients like wget just fail.
Thanks for the feedback - mnordhoff was correct in that the configuration pointed to cert.pem and not fullchain.pem - will monitor that chain for the next few days to see if any trust messages show up.
Also, the point re wget helps as it is a cronjob that is running the wget to produce a notification list for the website - in that case the --no-check-certificate on the wget appears that it is a requirement in this case.