The operating system my web server runs on is (include version):
centos 7.6
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):
N/A
I cannot remember, but I assume when I configured the server in 2018 I created a self-signed cert and configured the system to use it; At some point I installed certbot and switched over.
Just recently someone pointed out that the www version of the site is broken – it points the default apache site and not where it’s supposed to. Also the site is insecure and I can see it’s using a self-signed cert.
I have looked hard and I can’t figure out where the self-signed cert is coming from.
The only code in the vhosts is what certbot added and looks right.
I suspect it’s in the ssl.conf file, but when I try to comment out the lines:
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
apache breaks.
I have no idea how I did this or how I can undo it.
I’ve grep everything I can think of and I can’t find where the cert is coming from.
At my wits end
additional information:
There are multiple domains and it seems that the ServerAlias is the key. Whatever is the ServerName works and whatever is the Alias is using the bogus cert.
I’ve seen this type of problem multiple times in different threads on this forum lately. It seems like there are multiple configurations running as evidenced by the different certificates and content being served. I’m not surprised that commenting out those two lines caused issues as the location of the certificate and its private key would be unknown at that point. I’m hoping that one of the people who are really good at solving these configuration issues pops in soon. I’m a developer and more of a process guy.
Theoretically you should have a permanent (301) redirect (from www to non-www in your case I believe) and no alternate content to serve.
Re a redirect-
I added a redirect in the http vhost and it works; however, when I put the same code in the https vhost – it never gets hit – I assume the cert problem rears its head before the redirect can take place.
I sent a message to one of the most experienced guys here of solving these types of issues. The problem you're seeing appears to be a trend, hopefully with a common root.
Glad that worked. I’m curious as to how that solved things, but working is better than not. You probably still want to fix that redirect for search engine optimization purposes. You typically want a single, canonical address for search engines to tie your traffic to. It also makes bookmarking and referencing your site more consistent. I opt for the non-www myself to shrink what appears in the address bar.