Unexpected SSL Certificate Behavior and Switching Between Certificates Without Change
I'm experiencing a strange issue with my domain. The Cloudflare proxy is currently disabled, and the SSL/TLS setting is configured to Full (strict).
However, I’m encountering the following behavior:
- When the proxy is enabled, visitors receive an invalid SSL certificate, which does not match the domain or expected Let’s Encrypt cert.
- When the proxy is disabled, the correct Let’s Encrypt certificate appears intermittently, but sometimes a Cloudflare-branded certificate is presented instead.
The IP address always remains the same, and I have not made any recent changes to the certificate setup in Plesk.
DNS is set to “DNS only” (gray cloud) for all records, and the domain resolves properly from external locations.
The correct Let’s Encrypt certificates are still installed and active in Plesk for all relevant subdomains.
Locally, a request with curl -v mydomain.tld shows renegotiation attempts and sometimes switches between certs.
The server itself occasionally cannot resolve the domain due to Temporary failure in name resolution, although this seems to be a local DNS config issue.
To my knowledge, no one has changed or imported certificates, and yet the cert behavior is inconsistent and unpredictable.
42 Replies
Browser cache / dns cache
?dns-cache
DNS cache
Resolving DNS entries is complex and involves many parties (your browser, your operating system, your router and then your ISP's resolver).
Any and all of these intermediaries can potentially cache your DNS request and serve stale content, even though you just updated it.
Quick fixes:
1. Use a different browser
2. Restart your PC
3. Change your DNS from your ISP's to Cloudflare's: https://one.one.one.one/dns/#setup-instructions
Grey cloud means cf doesn't do anything except serve the dns record
I understand the role of browser caching, but this issue started suddenly without any changes on our end — no DNS updates, no SSL certificate changes, and no Cloudflare setting adjustments. The certificate actively switches between our valid Let’s Encrypt cert and an unexpected Cloudflare cert, even in fresh curl requests or incognito mode, which should bypass browser cache entirely.
Additionally, the issue persists across multiple devices and networks, and curl output shows repeated TLS renegotiation and inconsistent certificates, which cannot be caused by browser cache alone.
oh that's a origin cert
as the name implies you deploy this at your origin
this cert was either manually created by you, or through an api request that was authorized for your zone
origin certs aren't meant to be trusted by browsers
Ah okay, that makes sense
Thing is, none of us actually created that origin cert, not manually or via API (at least not knowingly)
Do you know where we can remove or disable it?
https://dash.cloudflare.com/?to=/:account/:zone/ssl-tls/origin
shows a list of all issued origin certs and you can also choose to revoke them
I just checked that link, and it says "no certificates"
that's very peculiar, let me check something
could you show the certificate details as well?
that's... a weird certificate to say the least
or
xn--v6q26ld9fa522d720cda022tca251hfa552ep12b.com is your domainHaha nope, definitely not our domain
well it is a domain that's using cloudflare
erm
our domain is identityvalley.de
honestly i have no clue how that certificate ended up in your hands, i'd recommend waiting for a community champ or someone else who actually knows what they are talking about lol
and how is that relevant
or are you associated with ole
yes
Alright, fair enough 😅 Appreciate the help anyway! Gonna hang tight and see if someone more deep into this chimes in. Super weird issue though…
What is your origin?
Our origin is hosted on a dedicated server with a fixed IP (94.143.231.68)
DNS over Discord: A records
identityvalley.de. A @8.8.8.8 +noall +answer
diggy diggy hole
Do you see that certificate present on your origin?
Idk how it got there, but if you see it, you might at least be able to get rid of it
I already took a quick look over my origin and I don’t see that certificate there. A deeper look I’ll take in the next minutes. The weird thing is, for about 30 seconds the correct cert is served and the site loads fine, then after around 30 seconds it switches back to that strange Cloudflare cert again — and this keeps looping.
We have thoroughly searched the server for the SSL certificate. We checked all common locations as well as the Plesk certificate manager. However, we cannot find the certificate file that matches the unexpected Cloudflare Origin certificate that sometimes appears.
The only certificate we find and use on the server is the correct Let’s Encrypt certificate installed via Plesk. Despite this, the server intermittently serves a completely different certificate for a foreign domain, which we cannot locate anywhere on our system.
Is it your own bare-metal server? Is there anything between it and the open internet? While it is a Cloudflare cert, it can't be injected by Cloudflare, since you are hitting your IP address directly, and Cloudflare wouldn't be serving an origin certificate anyway
It is really weird that it is someone else's origin cert that is being served, no idea why that is happening tbh, might be compromised/someone has found that cert and copied it on to your server by mistake
didn't want to outright suggest origin compromise but that was my initial guess as well
Yes, it’s a dedicated server rented at Avoro. On that server, we run Proxmox with multiple VMs. The VM with Plesk is directly exposed to the internet without any proxy or firewall in front.
I had that suspicion too, but I can’t explain how or where this weird certificate came from.
The certificate definitely comes from your server. I'd start by checking which service is running on port 443/8443 and carefully checking config files for that service to see where requests actually end up.
Also, disable whatever service is listening on 443/8443 and see if the certificate is still served to check whether anything is going on before the actual service.
I stopped Nginx on port 443, but the certificate is still being served.
Also ran
sudo lsof -i :8443, and it seems like the sw-cp-ser process is listening there:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sw-cp-ser 661 root 7u IPv4 14180 0t0 TCP *:8443 (LISTEN)
sw-cp-ser 661 root 9u IPv6 14182 0t0 TCP *:8443 (LISTEN)
So it looks like that might be the one providing the certificatesw-cp-ser is Plesk's webserver
But I still see the cert on port 443 even now. Is nginx still disabled?
Yes, nginx was actually still disabled. However, I just shut down the VM so that nothing else happens overnight.
Even though the VM is off, the values from the certificate still appear on the page?
I am confused
did you check what's running on 443/8443 on the host system?
On the Host on Port 443 runs nginx for proxmox
The VM has another public IP than the proxmox Host
If possible, I'd quickly shut down the host to verify it's even coming from your server.
Is the host's nginx running on both 443/8443?
no, only 443
I see the same cert served on 443 and 8443, but not on any other ports
Do you have any other IPs that are routed via the same host machine? They are all error free?
https://mail.identityvalley.de is Running on another IP in an VM, error free
hmm, I see the same cert for IPs from .68 up to .71
Anything those have in common?
I just have a suspicion, the other IPs don't belong to us. The next one is .74, which is ours. However, I'm a little confused about .68. I need to discuss this with the hoster. I'll get back to you tomorrow morning. Thanks in advance for your help.
Good luck in finding the cause of this, I'm going to bed as well 😉
Good morning, Just wanted to give you a quick update – we found the root cause of the issue.
Turns out my suspicion from last night (based on your observation "I see the same cert for IPs from .68 up to .71") was spot on. During the server setup, we mistakenly configured one of our VMs to use the IP .68, even though that IP was never officially assigned to us.
The strange certificate we've been seeing was actually served by another customer’s server – which explains the inconsistent behavior and why it seemed to switch every 30 seconds. Most likely some kind of IP conflict or shared routing situation on the network layer.
To be honest, I’m still a bit confused about how things were working at all for so long, but at least the issue is resolved now.
Thanks again to all three of you for your help and input last night – really appreciated!