[ssl:warn] AH01906: server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)

Ah, yes, sometimes people do that. I don't think that is happening here. They are getting certs every couple days and it looks like some sort of panel. This cert renewal frequency is a problem yet to resolve here.

@Kharon Are you manually disabling the proxy setting when you get certs?

Or, you can just wait for Cloudflare to redirect HTTP to HTTPS and it send the HTTPS request to the Origin. Then handle the challenge in the Origin on port 443 instead of port 80.

3 Likes

That is very helpful. I used that to check the cert used by your Apache given different kinds of requests (good SNI, non-SNI, faulty SNI). I was looking to see if the "localhost" cert was used in any of these cases.

None of these requests used the "localhost" cert. For non-SNI and faulty SNI I see the corriere24 cert. This is probably because the corriere24 VirtualHost is the default in your Apache. It is expected to see the default cert for these faulty requests.

This makes me think the "localhost" cert is not related to your Apache.

Do you have any kind of firewall between chrome and the public internet? Some kind of firewall that inspects outbound HTTPS requests maybe?

Do you recognize that "localhost" cert at all? Do you remember making it?

4 Likes

No.

Yes it is.

No.

No, through the control panel I simply dowload only the Let's Encrypt certs.

No. Do I have to delete it? I don't know how to proceed honestly.

Also through GSC I have the same feedback, one doesn't work and the other yes:

Cattura3

You may need to consult with a network security specialist.

Here are some things you might try to isolate the problem:

  • Disable Cloudflare DNS proxy so DNS points directly to your Apache server. Wait for the change to propagate (5mins TTL) and try chrome again

  • Install a different browser like Firefox on a failing device

  • Check every installed extension on Chrome. Anything related to security, spam, antivirus, or unknown could be disabled as a test.

  • Try chrome incognito mode

  • Use an entirely unrelated device like a friend's home computer

The reason for trying all these things is to discover the pattern of what is failing. Is it something on the devices you use, or how chrome is setup, or your local network, an ISP security setting, some rogue program, or any number of other possibilities.

Once you narrow down the possibilities you can better focus on fixing the underlying problem. It does not look to be certificate related or even related to how your certs are configured. It seems some sort of problem with your network, a security product, or even possibly a rogue program.

It is very strange. I am reaching the limits of what I can do. If nothing becomes clear after trying above you might be better off working with network security expert.

5 Likes

Dear @MikeMcQ

First of all thank you for all the efforts and especially helping despite my lack of knowledge: it doesn't happen in all communities...if you know what I mean. Really appreciated, you are truly unique.

I am going to try that.

Done, on my desktop pc I have intermittent "malfunction" also with Firefox.

Done, no appreciable outcomes after having disabled everything.

Done, the issue persists.

Done, their browsers don't have any problem to resolve the hostname.

Yes, the issue is probably local despite all the others websites from the same server don't have any problem with the devices/browsers/hardware I use on a daily basis.

Yes, that's weird. I am going to update if I can get to the bottom of it once for all.

Thank you once again!

2 Likes

Thank you. Given the consistent problems on the same device even with different browser and settings it is more likely something on the machine or local network. Especially so since you confirmed it didn't fail at a friend's computer (nor any that I tried from).

Think about any networking items that are shared between the failing devices. Any routers or firewall devices that might inspect outbound HTTPS connection. Check the DNS resolver config for each failing device. That sort of thing.

If disabling the Cloudflare proxy "fixes" the problem that's a whole different story. I just think that is unlikely but a fairly easy thing to do to rule it out for sure.

Yeah, that a different domain name on that same server works fine is very much a confusing part of this.

4 Likes

What does your "hosts" file look like?

'nix:
==============
cat /etc/hosts

Windows:
============================================
more %SystemRoot%\system32\drivers\etc\hosts

4 Likes
127.0.1.1 Kharon Kharon
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

162.55.37.58    mail.seomiotico.it      mail
1 Like

Let's see what the IP on the server is, with either of these:

  • ifconfig | grep -Ei 'inet|addr'
  • ip addr | grep inet
3 Likes
        inet 162.55.37.58  netmask 255.255.255.255  broadcast 0.0.0.0
        inet6 2a01:4f8:c17:1fe5::1  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::9400:1ff:fec9:c9d3  prefixlen 64  scopeid 0x20<link>
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
 inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
    inet 162.55.37.58/32 metric 100 scope global dynamic eth0
    inet6 2a01:4f8:c17:1fe5::1/64 scope global 
    inet6 fe80::9400:1ff:fec9:c9d3/64 scope link

Without pxoxying the DNS records it works like a charme and as it is supposted to do: it resolves instantly and continuosly (without any failure) the hostname.

But I need those records proxyed.

I start to suppose that maybe the two settings - one from control panel and the other from Cloudflare dashboard can't be enabled at the same time...I mean, one of them must be disabled.

do you think it is a good point?

If your Cloudflare is using Flexible Encryption mode, that would account for infinite redirects. Make sure that you are using Full (strict) Encryption.

4 Likes

I see you also had some trouble with HTTP->HTTPS redirect.

Are you sure that without Cloudflare proxied you were using the HTTPS version of your site (rather than using HTTP)?

Because if HTTPS worked without Cloudflare proxied then I would try enabling proxy again. I really can't imagine that is what caused the "localhost" cert to be seen but if you can easily reproduce it that is important to know.

And, yes, you must be careful about how HTTP->HTTPS redirects occur so as not to conflict with what Cloudflare CDN does when proxy the DNS.

4 Likes

Yes, sure.

Better ask to Virtualmin developer, hope that they can clarify to me.

2 Likes

Wow, that's really remarkable. I'd be very curious to know what happens when you re-enable the Cloudflare proxy.

2 Likes

Regrettably the anomalies described come back.

I kinda think you screwed up custom certificate upload: what kind of plan your CF account is?

3 Likes

That is interesting idea. How would that explain seeing the "localhost" cert only sometimes on certain clients? I don't ever see it and couldn't see wrong cert on other testing tools.

Could a wrong custom cert affect just certain Cloudflare CDN edge locations?

3 Likes

That's the free plan, which is then the same for the other domain mentioned that works perfectly instead. In that case, no need to switch to a business plan and upload any own SSl custom certificates. Or I suppose, because before the present time I did not notice any malfunctions with the combination of my control panel + CF.

Can perhaps this thread help? Regrettably I don't feel, however, that I have the competence to handle its contents.

Just trying everything...begging your pardon in advance.