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

Help
21

fullchain.pem = cert.pem & chain.pem
fullchain.pem = cert.pem + chain.pem
fullchain.pem = concat(cert.pem, chain.pem)
[shown in three ways... In case the first one wasn't clear]

So, unless you have a very old version of Apache, you shouldn't have to use the SSLCACertificateFile [deprecated] to include the chain - the fullchain file already includes it.

EDIT: I was thinking about "SSLCertificateChainFile" while writing.
[that is the setting that was deprecated with Apache version 2.4.8]
I still don't see why you should need to use "SSLCACertificateFile" at all.

3 Likes
22

I would say this is the scenario: there is no device/browser that always works. Of course, I have also tried frequent cache/history clearing but the problem returns even under anonymous search: in other words, intermittently, it is reported that the certificate is self-signed.

What bothers me most is that this website has the same same settings as the others that run on the same machine and are managed with the same control panel.

Perhaps it is a problem with Apache directives, yet even there the settings seem regular (and the same for all websites).

23

What shows?:
ps -ef | grep -v grep | grep -Ei 'apache'

2 Likes
24

The output:

root         967       1  0 Dec12 ?        00:00:04 /usr/sbin/apache2 -k start
www-data   31807     967  0 00:04 ?        00:00:00 /usr/sbin/apache2 -k start
www-data   31808     967  0 00:04 ?        00:00:16 /usr/sbin/apache2 -k start
www-data   31809     967  0 00:04 ?        00:00:20 /usr/sbin/apache2 -k start
25

They are all using 967, so there are no orphaned processes running.
It might be a caching thing [somewhere].

2 Likes
26

Might it be cleaned with an Apache restarting? (Even though I've already done it a few times over the course of these days).

27

For that, can you restart the entire server?

2 Likes
28

Do you mean reboot? Yes, even though I've already done it a few times over the course of these days.

29

I did mean reboot.
But if you've already done that, doing it one more time is not going to fix this problem.

2 Likes
30

With your domain proxied at cloudflare you will never see the cert from your Apache server in the client's browser. The chrome browser will see the cert from the HTTPS connection to the cloudflare CDN Edge.

It almost seems like there is a problem where sometimes the DNS resolver is giving you the wrong IP address.

Another option is that one of the IP addresses in your DNS is wrong. Make sure all 4 belong to cloud flare. I am not at a machine where I can check that right now

3 Likes
31

I have verified with Cloudflare assistance/community: my IPs are okay.

Moreover, I have seen under the running processes that certbot.service is Inactive (dead) despite is set to start at boot.

I have tried to restart it through the Virtualmin control panel (i.e. not Terminal) and it did not work.

Is that regular? Do I need that service running mandatorily in order to approach the solution?

Thank you in advance.

1 Like
32

Agreed:

I think it runs when needed.

3 Likes
33

Let's recollect:

  • SSLCertificateKeyFile loads the private key (you are doing this fine)
  • SSLCertificateFile loads the server certificate chain. That is the server certificate and its signing CA's sorted from leaf (certificate) to root (higher lvl CA).
  • SSLCertificateChainFile is deprecated in apache 2.4, so remove this one.
  • SSLCACertificateFile loads the CAs for clients that will authenticate through SSL with client certificate. THIS IS THE ONE YOU WANT TO USE FOR SSL CLIENT AUTH then.

My server stays on the latest Ubuntu LTS version. It is kept on the latest LAMP components. This week I upgrade to the new stable version of MariaDB. Every site I follow for Apache 2 states you want to use SSLCACertificateFile in your apache2 vhost conf file. In April 2024, Ubuntu 24.04 will be released. By September, my servers will be upgrade to it. Let's Encrypt needs to follow what Firefox, Chrome and other browsers are supporting because they open our web sites.

34

@scsiraidguru Please start your own thread for continued discussion of that issue. We are well aware of what Apache client authentication is and it is not related to this person's problem.

We do not like to mix two problems in the same thread here. Thank you

4 Likes
35

@Kharon I tried again this morning to reproduce your problem and cannot.

I tried many times using browers and other methods and always get a valid cert. The cert is the one I expect from the Cloudflare CDN (the Let's Encrypt E1 cert in this case).

When your chrome fails are you connected in the same local network as your server? Like using wifi for example? Because of course all my tests use the public internet.

If you post the public IP for your Apache server we could try some other things to identify the problem. Because it is proxied at Cloudflare we cannot connect to your Apache directly (Cloudflare does that connection).

3 Likes
36

In addition to my questions in my previous post can you provide one example of a domain name on that same server that is working?

3 Likes
37

When using the Cloudflare network , the typical way to handle SSL Certificates on your server is to either:

  1. Use Cloudflare's long-lasting "origin" certificates to encrypt traffic. These certificates are not publicly trusted and last for many years.
  2. Obtain publicly trusted LetsEncrypt certificates via the DNS-01 challenge, as the way to obtain HTTP-01/TLS-ALPN-01 certificates can conflict with the Cloudflare system. The only benefit/reason for obtaining LetsEncrypt certs yourself is as a failover for when Cloudflare is not handling your traffic - which is something that .000001% of cloudflare users will need. I've only needed to do this once in the last 10 years across dozens of domains.

If you are not obtaining the LetsEncrypt Certificates via DNS-01, you are likely creating DNS propagation and routing issues when you obtain certificates.

4 Likes
38

Can you explain more details of how that could cause this problem (see posts 2 and 3)? Because it seems highly unlikely their ACME client would use the Cloudflare API to disable and re-enable the DNS Proxy setting.

Handling HTTP Challenges with Cloudflare CDN takes some care but various methods are possible without disrupting the DNS settings.

4 Likes
39

The server's shared IP is 162.55.37.58

corriere24.com is a virtual server with the same configuration of the website examinated, I mean that it is on the same machine with the Let's Encrypt certificate properly running and has its DNS records proxied on Cloudflare.

40

Often times, someone will log into Cloudflare and disable the CDN routing for a FQDN to allow their origin server to obtain the certificate, then toggle the switch to resume the routing afterwards. This can result in some end-users getting the Cloudflare IP and others getting the origin IP until various levels of DNS caches time out.

You are right in that you can avoid this by using some specific Page Rules on Cloudflare to bypass changing DNS settings. Many/most people do not, and just do the DNS switch for a moment. What "works" to handle this has also changed in the past.

Edit: so the TLDR is that swapping DNS on this is very easy and often what people try first instead of doing things a more proper way with page rules and configurations.

3 Likes