LetsEncrypt SSL Cert Shows Name of Another Site on my SiteGround VPS Server

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: www.PureTekStore.com

I ran this command: Used Let's Encrypt tool in Cpanel on SiteGround VPS server

It produced this output:

My web server is (include version): Apache 2.4.29

The operating system my web server runs on is (include version): Linux Google Cloud (no version info available)

My hosting provider, if applicable, is: Siteground

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

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): Yes, Cpanel

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): Unknown, n/a

=====

Hello

I've reviewed many similar problems on this forum but none that I've found have my same environment.

I have several sites on my SiteGround VPS Server, which is hosted on Google Cloud (no details about linux versions, etc). They provide Let's Encrypt SSL certificates. Installing a certifiate is quick and easy. Just choose the Let's Encrypt tool, pick the kind of certificate (regular or Wildcard) and click Install. There are no other options. See SiteGround's page about Let's Encrypt here: https://www.siteground.com/tutorials/cpanel/cpanel/lets-encrypt/

So I was surprised to discover that several of my sites (including www.PureTekStore.com) report that their certificate is issued to a different site on my VPS server, specifically Aminoff.com.

Why would that be, and how do I fix this?

To answer the questions you're sure to ask:

  • Yes, these two sites (and many others) on this server share an IP address
  • Yes, there are other sites on my server with the same IP address whose Let's Encrypt SSL certificates were made the same way, but which properly report their own domain name in the certificate.

Here's the SSL Labs report on the PureTekStore.com site: https://www.ssllabs.com/ssltest/analyze.html?d=www.puretekstore.com

Here's the SSL Labs report on the Aminoff.com site: https://www.ssllabs.com/ssltest/analyze.html?d=aminoff.com

And here's the SSL Labs report on another site on the same server that has its own name properly assigned: https://www.ssllabs.com/ssltest/analyze.html?d=citrom.com

Any help or direction would be appreciated.

Thank you.

-Mark

2 Likes

Hi @WestHillsWeb,

Web servers like nginx, which seems to be used on this server, have a virtual host selection process that they use to try to match certificates (and site content) to requests from browsers. They will usually have a default fallback certificate, and a default fallback site content, when a match is not found. Because the certificate selection is based on the SNI protocol (in the TLS layer) and the site selection is based on the Host header (in the HTTP layer), these defaults don't necessarily even have to match each other, although they might match depending on the particular strategy that the server is using.

When you see the wrong certificate name returned in response to a connection request, it probably means that the system administrator has configured the server improperly, or that no exactly matching certificate is available at all. For example, for your first case (www.puretekstore.com), I see a certificate come back that matches puretekstore.com, but not www.puretekstore.com. That probably means that whoever (or whatever software) obtained this certificate neglected to include the www subdomain, which most browsers regard as a separate name.

If you're requesting these through cPanel, you should make sure that your own use of cPanel explicitly selects and configures every form of the name that you're going to use for each site (for example, including the www subdomains). If that still doesn't work, you'll probably need to ask SiteGround's support because the problem is then symptomatic of a misconfiguration in their hosting environment.

4 Likes

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