Universal SSL possible data corruption?

[apache.arpa]

Hello folks

I suspect that my website is experiencing problems with SSL connections, with some kind of misconfiguration on Cloudflare’s side, as I’ve been losing a lot of traffic for a year now, also regarding bad behavior with common attacks, are drastically decreased, and there’s a lot of unsecure requests. However, from my side I’ve never had any SSL problem.

I’m currently using Full (strict) config, and Universal edge certificate issued by DigiCert, with 1-year validity (why so long?), in DOCs I also read that DigiCert will be deprecated soon.

Whenever I try to disable and re-enable Universal SSL I always get the same certificate type, so DigiCert with 1-year validity with the backup certificate that expires after 3 months, when other websites using my same Cloudlare IPs are getting Google Trust Services certificates, though.

In the past I had also purchased a Certificate Manager subscription with Let’s Encrypt, but after 3 months the traffic continued to decrease. My suspect is that the certificate is not issued and/or corrupted in “sni cloudflaressl com” for my domain through several colos.

Now, since I can’t contact the support about this issue, even if Cloudflare is my registar, I was wondering if anyone of the support can deeply check the website’s SSL confs, or if there’re a way to completely reset the “sni/cloudflaressl/com” config, by hard coding or with some API’s request?

Maybe there’s a method to validate my suspicion

Thanks

[fritex]

Below article might help a bit:

Community Update - Deprecating DigiCert as a Certificate Authority for all SSL

Hi all, Cloudflare will be deprecating DigiCert as a Certificate Authority for all SSL certificate products (Universal SSL, Advanced certificates, and SSL for SaaS). The change will occur on the following schedule: Change Date New Cloudflare accounts will not have the ability to choose DigiCert as a CA for Advanced certificate orders August 30th, 2023 New Cloudflare accounts will not have the ability to choose DigiCert as a CA for custom hostname (SSL for SaaS) certificate orders Se…

I doubt you had lost web traffic due to this

[apache.arpa]

Thank you

My doubt was not for the type of certificate issued, but for the Certificate Provisioning incorrectly added to the SSL verification records by Universal SSL for all colos.

Since the domain uses A record for both ROOT and WWW without CNAME setup, I could try to move WWW to CNAME, as seen from the post below, but CNAME setup needs more data in DNS tab, but I don’t know what refer.

Community Tip - Best Practices For Certificate Provisioning

Error Try the suggestions in this Community Tip for best practices in certificate provisioning. Background SSL certificates can often be issued in 10-15 minutes. If you are using free Universal SSL, it can take up to 24 hours. Please do not reach out for support until it has been “authorizing” for more than a day. Before contacting support, you may be able to successfully trouble shoot the issue with some of these Quick Fix Ideas. [Dedicated SSL] Quick Fix Ideas If you are using a CNAME …

The site also uses HSTS and DNSSEC, so can I try disabling them?

Now the human traffic is practically null, when other websites in the same VPS are working fine with Cloudflare, so the problem is domain related

[DarkDeviL]

@apache.arpa

I suspect

Is that suspicion alone based on what you see as a loss of traffic?

@apache.arpa

problems with SSL connections, with some kind of misconfiguration on Cloudflare’s side

Any evidence of such problems (or the misconfiguration)? If so, please share it, so we can dig deeper with you?

That said, there is absolutely no way that the user(s) that you had, simply moved on and wanted to do something else, and that way “left” your site, so that the loss of traffic for example could be due to your user’s loss of interest?

@apache.arpa

The site also uses HSTS and DNSSEC, so can I try disabling them?

Stuff like that wouldn’t make a difference, as it your website appears to be working just fine.

@fritex

I doubt you had lost web traffic due to this

I’m 'ing on this.

[apache.arpa]

@DarkDeviL

Is that suspicion alone based on what you see as a loss of traffic?

My suspicion comes from the metrics, unsecure vs secure connections, almost 1/3 of the traffic is unsecure (therefore certificate not issued, not requested or totally not working) since the port 80 is externally closed.

When another website on the server has only minimally unsecure connections vs regular traffic.

@DarkDeviL

Any evidence of such problems (or the misconfiguration)? If so, please share it, so we can dig deeper with you?

The website has been on Cloudflare for almost 10 years now, and the domain is 20/yo, so I think I’ve some experience with that.

So I wanted to underline that not only human traffic has decreased but also regarding common attacks, eg Wordpress, Joomla, Cpanel etc. and the biggest attacks come almost exclusively from known host networks, Google, Microsoft, Amazon etc.

If domain has SSL connection problems of some kind, then it also loses its authority, I think, also because I see that now the website is no longer reached from various locations (Africa, India, South East Asia, South America, Oceania) only US and UK traffic mostly, including regular bots.

Also, not all errors are monitored on the CF edge, for example Bad Gateway errors on proxies (NGINX white pages) aren’t reported in the stats.

I think the only way to validate my doubt, is to remove the site from Cloudflare, but due to the firewall rules I can’t do that, so just move it to another server with its valid certificate once I leave Cloudflare

[DarkDeviL]

@apache.arpa

My suspicion comes from the metrics, unsecure vs secure connections, almost 1/3 of the traffic is unsecure

I would probably go as far as to say that you cannot base it alone on that:

@apache.arpa

(therefore certificate not issued, not requested or totally not working)

There are certificates issued for the domain mentioned, valid certificates that works perfectly.

So first part (not issued) as well as the last part (totally not working) falls apart here.

Not requested is however a different question.

If I am requesting your site as http://, that would come up nuder “None (not secure)”, if my device leans towards the http:// version, and then your server decides to redirect it to https:// afterwards, then I will still count as a request for “None (not secure)”.

If I am running a legacy system from the Stone Age, and that it does not trust your certificate, that would mean that I could end up on “None (not secure)”, but that I will NEVER get to TLS v1.2 or TLS v1.3.

If you have disabled e.g. TLS 1.0 and TLS 1.1, you’re similarly excluding secure connections from some of those legacy Stone Age systems, meaning that I would end up on “None (not secure)”, but likewise NEVER get to TLS v1.2 or TLS v1.3.

Should you try to eliminate those legacy connections, or attempt to still be supporting them?

While I can give my recommendations about which directions I would take there, I cannot make the final decision for you.

@apache.arpa

since the port 80 is externally closed.

You can decide whether or not that your server (behind Cloudflare) has port 80 externally closed.

Cloudflare has it “externally open”, when you’re having Proxied () records.

A HTTP/Port 80 request to your site, on Proxied () records, will therefore work just fine, and the connections to Cloudflare’s HTTP Proxies on port 80, are the ones ending up in “None (not secure)”.

@apache.arpa

so I think I’ve some experience with that.

For this one, if I’ve said something that you understood as that I was questioning your experience, expertise, or otherwise talking down to you, or stuff similar to that, that has → NOT ← been my intention.

I am simply trying to do my best, to help you.

@apache.arpa

So I wanted to underline that not only human traffic has decreased but also regarding common attacks, eg Wordpress, Joomla, Cpanel etc. and the biggest attacks come almost exclusively from known host networks, Google, Microsoft, Amazon etc.

If domain has SSL connection problems of some kind, then it also loses its authority, I think, also because I see that now the website is no longer reached from various locations (Africa, India, South East Asia, South America, Oceania) only US and UK traffic mostly, including regular bots.

If either the human visitors or the bots are staying in the Stone age as mentioned above, that one could indeed give problems.

Cluodflare has always, on the Free plan, been limited to “modern” browsers.

@apache.arpa

I think the only way to validate my doubt, is to remove the site from Cloudflare, but due to the firewall rules I can’t do that, so just move it to another server with its valid certificate once I leave Cloudflare

I’ve tested from multiple locations across the world, and there, your site appears to work just fine.

That said, I am under the impression that if there are actually errors within Cloudflare, that it is in Cloudflare’s interest to get them fix fixed.

You’re however having a lot of assumptions, guesses, “I think” around your stuff, which makes it hard (if not impossible) to dig deeper in to the case, as your site actually appears to work just fine.

In other words: How exactly do we reproduce the situation you appear you see?

@apache.arpa

When another website

Can you share the domain of that other website?

That way, we could at least look in to how and what appears different, from the one website to the other.

[apache.arpa]

Thanks for the suggestions.

@DarkDeviL

f you have disabled e.g. TLS 1.0 and TLS 1.1, you’re similarly excluding secure connections from some of those legacy Stone Age systems, meaning that I would end up on “None (not secure)”, but likewise NEVER get to TLS v1.2 or TLS v1.3.

Should you try to eliminate those legacy connections, or attempt to still be supporting them?

But in the past, I had also activated the TLSv1 in legacy connection, but it didn’t change the situation, even having a Pro account, so I had decided to cancel the subscription, since it’s useless having my amount of traffic, so I had bought the ACM subscription, to support a low SSL level, but after 3 months nothing has changed.

I would like to mention, that old browsers don’t pass challenged pages, since CF blocks access by displaying a system deprecation message, so even activating legacy connections, old browsers don’t pass, at all, although, this traffic is always “counted” in CF stats.

@DarkDeviL

You’re however having a lot of assumptions, guesses, “I think” around your stuff, which makes it hard (if not impossible) to dig deeper in to the case, as your site actually appears to work just fine.

In other words: How exactly do we reproduce the situation you appear you see?

Having changed many options in the dashboard, I’m pretty sure I can’t solve the situation in a short time, and as I said before, the only way to verify my doubts is to remove CF and move the website, also because, there’re several posts in community, about users who complain the same situation, even losing domain authority, with others who have abandoned the service permanently.

I’m convinced that not even CF’s techies know the system deeply, and several websites can suffer from issues that are impossible to trace, maybe just using an external software, such as wireshark to collect packet captures with traffic analysis, and see what happens, but too difficult to implement in the real world.

Also, mine is a very simple website, no databases, no CMS software, just static html pages, and the server is fully tested to work well with the latest technologies, so H2 and TLSv1.3, and internally no SSL errors are shown or reported with both Openssl and Curl, using the CF Origin certificate in full strict.