Stolen cert? Please help

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., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: Renewed cert

It produced this output: Worked, but cert automatically stolen?

My web server is (include version): Apache/2.4.29 (Ubuntu)

The operating system my web server runs on is (include version): Ubuntu 18.04.3 LTS

My hosting provider, if applicable, is: digitalocean

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, Wordpress site.

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):certbot 0.31.0

I am running a Wordpress site. I’ve renewed the cert a number of times, from the command line, and now this time around using “SSLZen” WP plugin. I have an activity log watching website traffic, almost immediately after renewing the cert the activity log shows traffic to the following site and then shows that they are attempting to use the new cert I generated. Wordpress and Woocommerce updated, plugins updated. I’ve searched but haven’t found a clear answer. My first question is, does this indicate that my private key has been compromised? In which case, it would seem it is being automatically stolen.
Any direction greatly appreciated,

1 Like

I’ve stolen your certificate too! Check it out @


Welcome to the Let’s Encrypt Community :slightly_smiling_face:

Some clarifications first:

  • Your certificate can’t really be stolen because it’s publicly available.
  • If your private key corresponding to the certificate were leaked, that’s a problem.
  • It does no good for another site to use your certificate without your private key.

You are asking precisely the right question.


It was suppose to be funny, thanks :stuck_out_tongue:

@TroyFromMars The hostname (as wel as my example above :wink:) point to the same IP address as your hostname. That’s not something you can prevent. As a consequence, browsers connect to, the IP address which is (also?) hosting your site and will be presented by a certificate from that server. In this case, it presents the certificate of your site.

Could be a typo in the DNS zone of, I don’t know. Might be because of some other cause.

Another fun fact: your site isn’t reachable through port 80. While people visiting your site through Google might connect nicely through HTTPS (which is working), when someone would enter without the https:// part (who does that?) in the address bar of their browser, they’ll get a time out error.

I have no idea what you mean by this exactly. The server presents the certificate during the handshake, so your question isn’t even valid, as the handshake was already started.

1 Like

This explanation even makes less sense to me than your previous one. What do you mean exactly by “establish a session”? How do you mean “leads to knowing if private key stolen”?

Ah, like that. Well, as far as I know, webservers won’t even accept a certificate without a corresponding private key in their configuration. So that scenario wouldn’t be possible.

1 Like

That’s what I figured, but a rogue installation might attempt such a thing (without success).

1 Like

Well, it’s often possible to just click on “Continue anyway” or whatever bypass method your favorite browser has… If it connects without a new error, the private key was “stolen”… Except in this case, it’s the same server as the legitimate site… So there’s nothing to steal, it’s the rightful place for the private key. You’re even seeing the ligitimate site when you click the error/warning away.

Not always. Check

PS: But Curl or something else works:

D:\temp>download -h
SSL error: RemoteCertificateNameMismatch
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate
Date: Fri, 04 Sep 2020 17:56:57 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Set-Cookie: PHPSESSID=276cid23jq78s2sjfp1opkq8f3; path=/,wp_woocommerce_session_6a4f9fac996ca98c6e22f13882747a50=9ae6b4c7e1c7a28839641f66311292a3%7C%7C1599415017%7C%7C1599411417%7C%7C83e1a39663e29520b4e93a88693bbb32; expires=Sun, 06-Sep-2020 17:56:57 GMT; Max-Age=172800; path=/; HttpOnly,yith_ywraq_session_6a4f9fac996ca98c6e22f13882747a50=3d79d417f9fb58c80b7e01f8585cced2%7C%7C1599415017%7C%7C1599411417%7C%7Caa1b9ded2e1715aafbe7cc077d282fc7; expires=Sun, 06-Sep-2020 17:56:57 GMT; Max-Age=172800; path=/
Server: Apache/2.4.29 (Ubuntu)
Link:; rel=“”,; rel=“alternate”; type=“application/json”,; rel=shortlink
Vary: Accept-Encoding
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

Status: 200 OK

690,80 milliseconds
0,69 seconds

PS: Small security info: @TroyFromMars : Your system shouldn’t create cookies if the host name is unknown.


You mean b/c of HSTS? That’s a whole different story altogether. But indeed, my “always” isn’t correct… Stupid me… In my line of work “always” and “never” do not exist. :stuck_out_tongue:

1 Like

I’m sure he has many questions :smiley:

1 Like


A browser doesn’t connect a domain name.

A browser checks the DNS (domain name system) to find an ip address of your domain



Then the browser connects the ip address and says:

User-Agent: Mozilla/5.0

Not completely correct, but one step earlier the SSL connection is created. The browser connects the ip and says: “I want an answer from, please send a valid certificate”.

So if there is (like the domain ) a typo in the A record of that domain name or an expired information (or a wrong created entry like A record -> your ip address), users connect your ip address and send an unknown domain name.

Your server answers with the standard certificate - that’s yours.

Nothing hijacked. That’s how the internet with SNI works.




Are you on “shared hosting” ?

It seems your vhost is the “default” and all “unknown” HTTPS connections end up connecting to your site.

Your renewal action is unrelated to the following connection (mere coincidence).

If you try:
openssl s_client -connect -servername none
You will see that the cert from your site is always presented (recently renewed or not).

If you are NOT on “shared hosting” you can make a “default” vhost config to “catch all” these random connections.


This actually doesn’t have to be a SNI thing. A server with just one “host” (can’t really call it a “virtualhost” if there’s only one now can we :stuck_out_tongue:) will always serve the same certificate, with or without SNI. Doesn’t really have to understand the SNI field too, it’ll just ignore it.


It’s that it’s the default when no server name is presented. Sounds like SNI to me…


Yes, I was just rewording it and giving some additional info so that even a passing simpleton can understand what is actually happening here.



Absolutely. I like what you’ve presented Rudy. :slightly_smiling_face:


True. Anything finite multiplied by 0 is 0. :upside_down_face:

Please read what SNI is and what it’s not, then read again what I posted.


How do you know? How do you know @TroyFromMars’s server actually has multiple virtualhosts configured? How do you know it’s just not a configuration for a single site, i.e. You do realise a webserver will also serve a certificate without SNI, right? How would SSL otherwise ever have worked in the era when SNI didn’t exist?