Hi,

On Thu, Oct 12, 2023 at 6:24 PM Frederic Ayrault <fred@lix.polytechnique.fr> wrote:

Le 12/10/2023 à 17:42, Florence Blanc-Renaud a écrit :

Hi,

The CA installation fails because it finds an existing entry in "cn=LIX.POLYTECHNIQUE.FR IPA CA,cn=certificates,cn=ipa,cn=etc,dc=lix,dc=polytechnique,dc=fr". It really looks like your topology used to have a self-signed CA at one point.

If you look at this entry, does it correspond to a CA known to you?

You can extract the certificate using

ldapsearch -D "cn=directory\ manager" -W -b "cn=LIX.POLYTECHNIQUE.FR IPA CA,cn=certificates,cn=ipa,cn=etc,dc=lix,dc=polytechnique,dc=fr" -LLL -o ldif-wrap=no

which should show a value for cacertificate;binary:: <content>

Then create a pem file with the format

-----BEGIN CERTIFICATE-----

<here paste the content>

-----END CERTIFICATE-----

and execute: openssl x509 -noout -text -in <pemfile>

I can see in Authority Information Access:

OCSP - URI:http://ipa2.lix.polytechnique.fr:80/ca/ocsp

this is the server used to generate the replica-info-ipa3.lix.polytechnique.fr.gpg file used to install the server

openssl pkcs12 -export -chain -CAfile /root/CNRS2-All.crt -in ipa3.lix.polytechnique.fr.pem -inkey ipa3.lix.polytechnique.fr.key -name IPA3 -out ipa3.lix.polytechnique.fr.pk12 -passout pass:???
ipa-replica-prepare --dirsrv_pkcs12=/root/ipa3.lix.polytechnique.fr.pk12 --dirsrv_pin=??? --http_pkcs12=/root/ipa3.lix.polytechnique.fr.pk12 --http_pin=??? ipa3.lix.polytechnique.fr

the CNRS2-All.crt is the same for all the servers and I get a pair of pem and key files for each servers

In CNRS2-All.crt, there are 3 certs from Issuer: C=FR, O=CNRS, CN=CNRS2

You mentioned in a previous email that the server was originally part of a cluster but got "extracted" out of it to run the tests. Did this set of servers have a self-signed IPA CA? In the logs we can see reference to 3 different CA certificates for "CN=Certificate Authority, O=LIX.POLYTECHNIQUE.FR" (self signed, issued in june, june and july 2016). It's really a confusing situation, as it's the subject that IPA CA would use by default but it could also be a completely different origin.

I do not know how was installed the first server, but everytime I add to renew the cert, I removed the server, generate the gpg file
and did a replica-install

This procedure is very creative :)

When the HTTP and LDAP server certificates are about to expire, there is a tool that can help you install new ones: ipa-server-certinstall. It is documented in Installing Third-Party Certificates for HTTP or LDAP. No need to scratch the machine and reinstall as a replica, simply replace the certificates.

I thougt using --ca-subject for the ipa-ca-install should solve the confusing situation. Can I delete or rename those 3 CA ?

Your current situation: there was a self-signed IPA CA in one of the servers, the replica was created without the CA role then extracted from the original topology. This means there are traces of the CA installation in the new replica but nothing to actually provide the service.

So my answer really depends on what you want to achieve. If the new replica will never be connected any more to the previous topology, you could follow Fraser's blog about Removing the CA from a FreeIPA deployment on the replica after it has been removed from the original topology, ensure that everything is cleanup and call ipa-ca-install on the new replica. This would ensure there is a new CA private key completely different from the original one. Please note that this blog provides instructions but 1. this is not an officially supported procedure and 2. the instructions intend to remove the CA, not reinstall a new one later on.

flo

flo

Frédéric