Intermediate CA mismatch between two servers

Help
1

I failed to find similar issue in forum so had to open new topic and I hope will get some advice.

We use a script which we run manually (inside a venv) to generate and renew certs to remote clients within our domain.
Currently we have harded as ROOT CA in script ( ..--non-interactive --preferred-chain "ISRG Root X1") . I am unsure if this is correct way but this is how it is.

We have two redhat servers which need to work together to serve repositories to clients. The process of deploying generated/renewed certs in these two servers is quite e tedious one but it does work in the end.

Only just last few days we had to renew SSL for one of these servers, the renewal cert files when running renewal script (using certbot) were succefully deployed to server. To be short however, we lost communication between these two servers after renewed certs. The redhat support confirms that communication is lost due to mismatch of intermediate CA's. Main server has CN=R11 and second one (just renewed) CN=R10. I checked old CA's on same server and they contained CN=R11. My question is how come and why Letsencrypt decided to use R10, whereas used R11 before. Is there a way we can fix this via cerbot to force use of R11 instead of having to manually copy CA's between these two servers, being the only option at this moment in time.

Our intention is prevent similar happening in the future as this affects a number of systems depending on these two servers and repositories they serve.

I hope I am clear enough to get some help on this topic.

2

@vj-diam, welcome to the community!

The selection of the intermediate signing certificate used is random between R10 and R11. When deploying the leaf certificate, deploy if with its own signing certificate (already downloaded together with the leaf at certificate issuing time).

3 Likes
3

See: Chains of Trust - Let's Encrypt

Also R12-R14 are backups which could be used any time although hopefully not.

ECDSA certs have a separate set if you start using those

For background: New Intermediate Certificates - Let's Encrypt

The API section is good to subscribe to for important notices like this one: Deploying Let's Encrypt's New Issuance Chains

3 Likes
4

Thank you for your prompt reply. For deploying generated ceritficates to mentioned servers (Satellite and Capsule), there is a procedure we need to follow and run few commands, is not just matter of pointing to correct files/directories.
Based on your answer we can then only hope that next time we generate certs the intermediate CA we want is going to be used by Letsencrypt.

1 Like
5

You have deployed an anti-pattern. Your systems should expect that ANY intermediate may be provided by the ACME server on any request. Your systems should expect to download and install the Chain in addition to the Certificate. This can be done by either using the "certificate + chain" or the "fullchain" (which is Certbot's name for concatenating the two files).

5 Likes
6

Then you really, REALLY need to address this system, because hardcoding an intermediate is NOT the correct way to do things.

The ACME server sends a single chain to the ACME client: the end leaf certificate and the intermediate that signed that end leaf cert. One should use this intermediate and not a hardcoded one.

Maybe you need to modify scripts, programs or what not, but they surely need modification if they're using a hardcoded intermediate.

5 Likes
7

It's very likely you are deploying your certificate file but not deploying the intermediate CA bundle. The easiest way to do this is normally to use the "full chain" file instead of the "certificate" file.

Looking at some likely looking instructions here: Chapter 12. Renewing the Custom SSL Certificate | Red Hat Product Documentation they mention the ca_cert_bundle file, this has to be the latest file from your renewal, not some other file that you keep handy elsewhere ro one you have compiled yourself.

It looks like they provide a handy utility katello-certs-check to check your files before you try to apply them.

4 Likes
8

Yes, I did not see the need to go into those details, but all the steps mentioned there are stricly followed. After renewed certs by Letsencrypt, we then run katello-certs-check, which uses file paths to the new renewed cert files including ca_cert_bundle, once all confirmed correct then continue with other steps. The certificate is successfully deployed but end result is lost communication between two servers, apparently because of intermediate certs mistmatch according to redhat support. I hope is clear.

9

Not really. Because what would be the cause of the mismatch if the correct intermediate is being send by the server?

Do you have examples? E.g., URL giving the trouble or detailed error logs?

4 Likes
10

For reference, here are the Satellite and Capsule docs relating to custom certs.

Out of curiosity, what are you using for the various files referenced by the installer?

satellite-installer --scenario satellite \
--certs-server-cert "/root/sat_cert/satellite_cert.pem" \
--certs-server-cert-req "/root/sat_cert/satellite_cert_csr.pem" \
--certs-server-key "/root/sat_cert/satellite_cert_key.pem" \
--certs-server-ca-cert "/root/sat_cert/ca_cert_bundle.pem"
3 Likes
11

My first thought on reading that is "This does not look like it should be using a Public CA".

Then I read a bit more, and here we go:

3.5.8. Configuring Satellite Server with a Custom Server Certificate

SSL certificates are used to protect information and enable secure communication. Red Hat Satellite 6 creates self-signed SSL certificates to enable encrypted communications between the Satellite Server, external Capsule Servers, and all hosts. Instead of using these self-signed certificates, you can install custom SSL certificates issued by a Certificate Authority which is an external, trusted company. For example, your company might have a security policy stating that SSL certificates must be obtained from a Certificate Authority.

There is no need to use Public CA Certs. Using them on these systems is possibly a security risk, as the latter instructions talk about installing the certificate on the clients as well.

These systems were designed for self-signed certificates, with the option to issue from a Corporate CA.

Nothing in the docs suggests using a Public Trusted CA is warranted, and IMHO the docs teach away from using a Public CA and rely on private ones.

5 Likes
12

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