SSL certificate randomly switches from trusted to NOT trusted

Website, Application, Performance Security
1

What is the name of the domain?

Can’t disclose due to ongoing development with exposed APIs. It’s a .net domain

What is the error number?

NET::ERR_CERT_AUTHORITY_INVALID

What is the error message?

“Cloudflare Origin Certificate” certificate is not trusted

What is the issue you’re encountering

Our website, which uses Cloudflare with Universal SSL, at random runs into certificate problems. The certificate keeps switching between a trusted one (Baltimore CyberTrust Root) and an untrusted one (Cloudflare Origin Certificate) at random, leading to security warnings in browsers. It happens several times a day, sometimes affecting most visitors, other times just a few. It lasts anywhere from a few minutes to several hours. On top of that, we’ve noticed that sometimes the site works fine with the correct certificate (with Baltimore CyberTrust Root) on one browser, but shows as unsecured (with Cloudflare Origin Certificate) on another browser on the same device at the same time.

What steps have you taken to resolve the issue?

  • Checked that Universal SSL is on and set up correctly, even turned it off & on again and got assigned a new certificate (current Baltimore CyberTrust Root by DigiCert, before was Google Trust Services)
  • Made sure all domains are proxied
  • Made sure Force HTTPS is on

Was the site working with SSL prior to adding it to Cloudflare?

Yes

What is the current SSL/TLS setting?

Full

Screenshot of the error

i.png
i.png1176×404 90.7 KB

2

That would sound like the device (or browser) is connecting directly to the origin, and not through Cloudflare first.

I would suggest you to check the Audit Log page:

→ https://dash.cloudflare.com/?to=/:account/audit-log

It could sound like someone (or something) may be de-activating and re-activating the Proxy (:orange:) status for your record(s) every now and then, which would then appear in the Audit Log, if that is the case.

Switch that one to Full (Strict).

2 Likes
3

I checked the Audit Log page for proxy updates, and it’s clean.

When we first set up Cloudflare, it was set to Full (Strict) through early Monday to Wednesday. The site was pretty much inaccessible because of the unsecured warning all the time. After we switched to Full on late Wednesday, the unsecured warnings decreased to just a few hours a day.

We might consider changing it back to Full (Strict) because it looks like the issue isn’t fully resolved, but at the same time, Full (Strict) did perform worse for days than Full.

What also puzzles me is that the certificate appears for some users while it’s missing for others at the same time, sometimes for hours. In other cases, the certificate is present on one browser but missing on another browser on the same device. Could it be possible that the traffic is being proxied for some users but not for others for hours, even when they are using the same device?

4

When I switch some DNS record (e.g. the AAAA for test.example.com) from Proxied (:orange:) to Unproxied (:grey:) / DNS-only, - I see something like the following in my Audit Log:

cloudflare_community_681709_audit_log_disabling_proxy_status_via_dashboard
cloudflare_community_681709_audit_log_disabling_proxy_status_via_dashboard943×675 19.2 KB

If you are not able to find something like that, it wouldn’t suggest something at Cloudflare’s end, to be the culprit here.

To dig further in to that part, - I suggest you collect, at a bare minimum, the following two points from the users with issues:

  1. What ISP / provider, preferably their AS number?
    The AS number can be found here:
  1. What country (and preferably state/region)?

In addition, stuff like e.g. what OS, Browser and versions may be handy as well, to figure out if there is a pattern regarding the issues.

Including e.g. which browser is it that works, and which one is it that doesn’t?

A such mix wouldn’t be something that would come from Cloudflare’s end.

And definitely not related to Cloudflare, if the Proxy status is kept on Proxied (:orange:), and, … never changes from that (according to the Audit Log).

However, - it isn’t technically impossible, that if e.g. I know your origin IP address, that I could divert queries directly to your origin.

Some tech savvy users may even do something like that, during e.g. development of the website, or otherwise for testing (e.g. Cloudflare versus not), but it wouldn’t be something that would commonly be set up (or even known how to do so) from typical, non-tech savvy users.

In that case, I would dig in to your origin as well as your DNS records.

I’m not saying everything would necessarily be in your control, - however, it does sound like something in your set up is misconfigured somehow.

Unless you purposefully want to be overly deceptive towards your visitors, Full (Strict) is the only way to go.

9

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