As stated in the title, I have a website that lives in a virtual machine with a letsencrypt cert. Setting up letsencrypt via certbot went smoothly, but 4 days later, the cert on the site switched back to the name of the server, rather than the domain name. I went in and reissued the cert and cleaned out all the cert files from the setup, when it detected and tried issuing a cert for the hostname of the server - and it was fine for another 2 weeks.
After reissuing the cert again, I did a force renewal to doublecheck that it wasn't the renewal script causing the issue and it renewed without a problem.
Anyone have any insight on why this is happening? It is worth noting that the vm was a staging site for the website for some time, and had a url of its own during that time.
My web server is (include version): apache on RHEL 7
My hosting provider, if applicable, is: Databank
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): Certbot 1.13.0
Command I used for the setup:
certbot --apache -d mydomainname -d www.mydomainname
Could you be more explicit about what you mean by "switched back to"?
Did you start getting a certificate error in your browser because the server was presenting a certificate for a different name than the name you were trying to connect to?
By "the hostname" or "the server name", do you mean a name that's assigned by your hosting provider for your server VM instance, that's distinct from the domain name that you've registered and that people normally use to connect to your site?
Happy to do so - After the cert is installed, I navigate to the website and check the site info, view the cert info, and all the details of the cert are correct, with the Common Name matching the name of my website.
When it switches, I notice that the SSL is failing validation and the page is insecure. When I go into the site info to view the cert, the Common Name on the cert is set to the hostname of the server - the name provided by my hosting provider for that VM instance.
Hi @0nionboi and welcome to the forum! I'd like to gently remind you that if you go ahead and tell us your domain name, we'll be able to help you a lot more quickly and effectively. Easier for you, easier for us. All publicly issued certificates are searchable at via Certificate Transparency logs at https://crt.sh/ and elsewhere.
Haha I did read that originally, but the thought of it still wigs me out a little - the domain is brynathyn.edu
/etc/httpd/conf.d/ssl.conf:# Point SSLCertificateFile at a PEM encoded certificate. If
/etc/httpd/conf.d/ssl.conf:# Point SSLCertificateChainFile at a file containing the
/etc/httpd/conf.d/ssl.conf:# the referenced file can be the same as SSLCertificateFile
/etc/httpd/sites/01-brynathyn.oudeve.com.conf:# SSLCertificateFile /path/to/your_domain_name.crt
/etc/httpd/sites/01-brynathyn.oudeve.com.conf:# SSLCertificateKeyFile /path/to/your_private.key
/etc/httpd/sites/01-brynathyn.oudeve.com.conf:# SSLCertificateChainFile /path/to/CAfile.crt
*:443 is a NameVirtualHost
default server s06007.databank.host (/etc/httpd/conf.d/ssl.conf:56)
port 443 namevhost s06007.databank.host (/etc/httpd/conf.d/ssl.conf:56)
port 443 namevhost brynathyn.edu (/etc/httpd/sites/01-brynathyn.oudeve.com-le-ssl.conf:2)
wild alias *
*:80 is a NameVirtualHost
default server s06007.databank.host (/etc/httpd/sites/00-databank-monitoring-site.conf:4)
port 80 namevhost s06007.databank.host (/etc/httpd/sites/00-databank-monitoring-site.conf:4)
port 80 namevhost brynathyn.oudeve.com (/etc/httpd/sites/01-brynathyn.oudeve.com.conf:1)
wild alias *
Hey, that looks like something - s06007 is the common name that appears in my cert whenever it decides to stop using the one I manually create. Is it a matter of changing the default server? I'd probably have to work with the company that hosts the site, since I don't want anything else to break by making this change.
Huh! Is that company managing this server for you to some extent? Do you know how that VirtualHost came to have the "generic" hosting name explicitly listed in it in addition to your intended domain names?
The company built the site, and set it up in Databank for us, then handed it off to us. I'm almost positive that's from their configuration. Would that cause an error with Let's Encrypt? Even after I cleaned up the cert and force renewed it (to test the renewal), the configuration stuck. I'm still unsure what would cause it to switch to a cert for s06007.
If no ServerName is specified, the server attempts to deduce the client visible hostname by first asking the operating system for the system hostname, and if that fails, performing a reverse lookup on an IP address present on the system.
This is why I think my approach will work. You make a first virtualhost for domain you want, with the explicit server names, and then a second virtualhost/server for the default, which just redirects to the intended domain.
This gets around most servername issues I have encountered.
# never serve anything but a redirect on the default server
Redirect / https://www.example.com