Issue Plesk showing Cloudflare Origin CA cert, but server still serving Google Trust cert

[mauricekindermann]

Server operating system version

CentOS 7.9.2009

Plesk version and microupdate number

Plesk Obsidian 18.0.71.2

Hi all,

We’ve been troubleshooting an intermittent SSL handshake issue with Cloudflare (Error 525). Cloudflare is in Full (Strict) mode, and we’ve installed a Cloudflare Origin CA certificate in Plesk for our domain (valid until 2040).

Expected: Origin should always serve the Cloudflare Origin CA cert.

Actual: When testing with openssl, we still see a Google Trust Services (WE1) cert (valid until Oct 2025). That mismatch causes Cloudflare to periodically reject the connection.

What we’ve done so far:

• Verified in Plesk: only the Cloudflare Origin CA cert is assigned.
• Checked nginx config (/etc/nginx/plesk.conf.d/vhosts/...conf): all ssl_certificate directives point to the Cloudflare cert file.
• Confirmed that file really does contain the Cloudflare Origin CA cert (expires 2040).
• Ran plesk repair web <domain> -y — no errors.
• Reloaded nginx — no change.
• Yet openssl s_client connections still return the Google Trust cert.

Example outputs:

From config (expected)
ssl_certificate /usr/local/psa/var/certificates/XXXXX;
ssl_certificate_key /usr/local/psa/var/certificates/XXXXX;


File contents:
subject= /O=CloudFlare, Inc./OU=CloudFlare Origin CA/CN=CloudFlare Origin Certificate
issuer= /C=US/O=CloudFlare, Inc./OU=CloudFlare Origin SSL Certificate Authority
notAfter= Jul 4 00:57:00 2040 GMT

What clients actually see:
subject= /CN=domain.tld
issuer= /C=US/O=Google Trust Services/CN=WE1
notAfter= Oct 12 16:00:56 2025 GMT

Question:
Why is nginx still serving the old Google Trust / Let’s Encrypt cert, even though Plesk shows the Cloudflare Origin cert as active and the config points to it? Could something else be handling TLS on port 443 (e.g. Apache, sw-cp-server, or a catch-all vhost)?

Would appreciate pointers on where else to check or how to make sure only the Cloudflare Origin cert is actually presented to clients.

 

[Norjed]

We are troubleshooting a very similar issue on our side. In our case, the correct SSL certificate is configured in Plesk for a new subdomain, but externally the server still serves the fallback/default certificate. Locally with openssl everything looks fine, but from outside it fails — exactly like you described with Cloudflare.

This looks strongly related to the known bug PPPM-15085 in Plesk 18.0.72 (see this thread + this thread).

Additionally, we also noticed another problem after the update: in all access logs the client IP is replaced by the server’s own IP address, which makes proper logging almost impossible.

So most likely both issues are part of the same regression introduced in the latest updates.

 

[Norjed]

Just to clarify after more testing on our side:

• The issue where the wrong SSL certificate was served externally (while locally everything looked fine with openssl) turned out not to be a Plesk bug, but caused by BitNinja WAF 2.0 intercepting HTTPS traffic.
• A strange side effect was that all access logs (nginx/Apache) showed only the server’s own IP instead of real client IPs, which made it very confusing to debug.
• Even more oddly, this behavior only affected one specific domain on the same server, while other domains and subdomains worked normally with the correct cert.
• After disabling BitNinja WAF 2.0, both issues disappeared immediately — the correct certificate was served externally and client IP logging worked again.

So in our case this was BitNinja-related, not PPPM-15085 or a regression in Plesk 18.0.72, even though at first glance it looked very similar.

If anyone else runs into this, it may be worth checking third-party security layers (like BitNinja) in addition to Plesk itself.