LetsEncrypt randomly switching to issuing a cert to the hostname instead of domain name

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

For renewal I used:
certbot renew --force-renewal


1 Like

Hi @0nionboi,

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.

Hope that helps.

1 Like

Thanks! Is the non-matching certificate apparently valid, just not the right one for your domain name?

Could you try running certbot certificates to see which certificates you have that are managed by Certbot?

1 Like

Yes, that's the strange thing. The non-matching cert looks valid, but it fails the website validation because it doesn't match the URL/domain name of the site.

certbot certificates looks good - I see only this, which is expected:

Found the following certs:
Certificate Name: mydomainname
Serial Number: 3c562f5863bc79166d50b943f1061ac106c
Key Type: RSA
Domains: mydomainname www.mydomainname
Expiry Date: 2021-06-06 18:00:26+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/mydomainname/fullchain.pem
Private Key Path: /etc/letsencrypt/live/mydomainname/privkey.pem

Can you try this?

sudo grep -ir SSLCert /etc/apache2

or if you use CentOS or something else RHEL-like

sudo grep -ir SSLCert /etc/httpd

An alternative that could also be useful is

sudo apachectl -t -D DUMP_VHOSTS

1 Like

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. :slight_smile: All publicly issued certificates are searchable at via Certificate Transparency logs at https://crt.sh/ and elsewhere.

1 Like

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:SSLCertificateFile /etc/pki/tls/certs/localhost.crt
/etc/httpd/conf.d/ssl.conf:SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
/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/conf.d/ssl.conf:#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
/etc/httpd/sites/01-brynathyn.oudeve.com-le-ssl.conf.bak:SSLCertificateFile /etc/letsencrypt/live/brynathyn.edu/cert.pem
/etc/httpd/sites/01-brynathyn.oudeve.com-le-ssl.conf.bak:SSLCertificateKeyFile /etc/letsencrypt/live/brynathyn.edu/privkey.pem
/etc/httpd/sites/01-brynathyn.oudeve.com-le-ssl.conf.bak:SSLCertificateChainFile /etc/letsencrypt/live/brynathyn.edu/chain.pem
/etc/httpd/sites/01-brynathyn.oudeve.com-le-ssl.conf:SSLCertificateFile /etc/letsencrypt/live/brynathyn.edu/cert.pem
/etc/httpd/sites/01-brynathyn.oudeve.com-le-ssl.conf:SSLCertificateKeyFile /etc/letsencrypt/live/brynathyn.edu/privkey.pem
/etc/httpd/sites/01-brynathyn.oudeve.com-le-ssl.conf:SSLCertificateChainFile /etc/letsencrypt/live/brynathyn.edu/chain.pem
/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
    VirtualHost configuration:
*: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)
                 alias brynathyn.oudeve.com
                 alias www.brynathyn.edu
                 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)
                 alias brynathyn.edu
                 alias www.brynathyn.edu
                 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.

1 Like

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?

1 Like

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.

1 Like

I think the overlap between the virtual hosts defined in ssl.conf and 01-brynathyn.oudeve.com-le-ssl.conf is causing some troubles. Could you post the whole contents of ssl.conf?


I swtiched to nginx long ago, but from what i remember of apache... i think this issue could happen because the server block for the desired websites has a catchall and/or hostname on it.

i typically set the desired websites into a single explicit serverblock, then use a separate catchall/default to redirect to the desired domains.

if the issue is because of the defaults, switching to a dedicated server block should fix that.


I removed the commented out lines.

cat /etc/httpd/conf.d/ssl.conf

Listen 443 https

SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog

SSLSessionCache         shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout  300

SSLRandomSeed startup file:/dev/urandom  256
SSLRandomSeed connect builtin

SSLCryptoDevice builtin

<VirtualHost _default_:443>

ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn
SSLEngine on
SSLProtocol all -SSLv2 -SSLv3


SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

<Files ~ "\.(cgi|shtml|phtml|php3?)$">
    SSLOptions +StdEnvVars
<Directory "/var/www/cgi-bin">
    SSLOptions +StdEnvVars

BrowserMatch "MSIE [2-5]" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"


Now I'm confused about how this happens

if that name isn't mentioned anywhere in that file!

1 Like

Probably the servers own hostname:

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.

(core - Apache HTTP Server Version 2.4)


That's what it is. s06007 is his server's name on databank.host. Going to s06007.databank.host serves up the page below (which is not secure).


1 Like

I'm confused about how the server name is ending up in my SSL cert. Is that certbot's doing, or Apache?

1 Like

Apache. If you don't set a ServerName directive in <VirtualHost> section, Apache will use the hostname of the server. Please see the documentation I linked above.

1 Like

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.


<VirtualHost _default_:*>
   # never serve anything but a redirect on the default server
   Redirect / https://www.example.com
<VirtualHost *:443>
    ServerName www.example.com
1 Like

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