This is an important issue to address, bumping its priority. I discussed it with pviktori and pspacek and this is the result.

Current design: ipa-ca.$DOMAIN holds CNAME records of all IPA replicas with pki-ca installed. This URL is added to certificates that IPA publishes so that clients can check CRL or OCSP even if the origin replica which signed the certificate was decommissioned.

Problem: DNS record should not hold more than one CNAME record. Thus, replica install with --setup-ca will fail due to enforced validation in #3450 and because cNAMERecord attributeType is now SINGLE-VALUE (#3440). Users may already have certificates with this CRL/OCSP URL in them, i.e. we need to keep ipa-ca.$DOMAIN functional.

Potential solutions
1. Change ipa-ca.$DOMAIN to hold list of A records of IPA servers instead of list of CNAME records

• OCSP checker may fail to verify ipa-ca.$DOMAIN certificate as its name is now different
• When server IP address changes, nsupdate would not update ipa-ca too and thus CRL/OCSP checks would fail

1. Change ipa-ca.$DOMAIN to hold just one CNAME pointing to the first replica with installed CA. When this replica is being removed, ipa-replica-manage should either warn that ipa-ca DNS record needs to be updated or update if itself by picking random IPA replica with CA installed.

• One drawback: CRL/OCSP checks would not be able to fallback if the defined replica is down

I suggest a third option.

ipa-replica-manage should fail the delete command if a new argument is not provided. This new argument would define which replica should be used as a new CNAME value. The operation should also warn that the fallback would not work if the selected replica is down.

Replying to [comment:3 dpal]:

I suggest a third option.

I assume you mean a modification of the second option above.

ipa-replica-manage should fail the delete command if a new argument is not provided. This new argument would define which replica should be used as a new CNAME value. The operation should also warn that the fallback would not work if the selected replica is down.

Yes, this could be done as an enhancement for ipa-replica-manage (and probably ipa-csreplica-manage too). ipa-ca.$DOMAIN CNAME would practically link to the primary IPA CA that would be used for revocation checks.

My point is that if the new master is explicitly chosen we would be able to ad a real time check whether it is up and running at the moment of operation to ensure proper fail over. That would be a future enhancement that we can defer for now but it would be possible to add.

Yesterday we discovered that the whole ipa-ca CNAME concept doesn't work with real OCSP client (Firefox). The problem is that certificate validation process doesn't take CNAME redirection into account and whole validation fails because DNS name used for OCSP/CRL connection (ipa-ca...) != name in the SSL certificate (vm-something...).

What we found:

• CRL and OCSP responses are signed, so HTTPS is unnecessary (and adds unnecessary load to server)
• As a consequence, HTTPS can be dropped from CRL and OCSP URLs - plain HTTP is enough
• We can use ipa-ca name and replace CNAME with multiple A records. Client should fail over to another replica if one of addresses is not reachable. This should not create any issues because HTTP is used for transport.
• Now we have to solve the problem with re-issuing certificates, because certificates issued by current IPA contain https:// protocol in OCSP URLs - and it doesn't work.

Shouldn't we prepare hotfix to lower the total count of certificates with invalid OCSP URLs? Hotfix = substitute https with http in profile used for certificate generation.

At least we could write some wiki/KB article with steps necessary for changing certificate profile...

The reason for using a CNAME was to handle the case where a CA disappeared completely.

Currently NSS does not use multiple OCSP entries, so if anything we'd want to continue with the CNAME and add only a single master to its entry in DNS.

Opened a ticket for the HTTPS URL issue: #3552.

Replying to [comment:8 rcritten]:

The reason for using a CNAME was to handle the case where a CA disappeared completely.

Currently NSS does not use multiple OCSP entries, so if anything we'd want to continue with the CNAME and add only a single master to its entry in DNS.

This seems as a big deficiency to me as it renders the whole failover concept nonfunctional. For example Firefox can now fail if it chooses to tries the OCSP defining a hostname of IPA CA singing the cert before trying the ipa-ca.$domain one. This will make the https request to fail even though ipa-ca.$domain points to a valid IPA CA.

Are you aware of any open NSS Bugzilla planning to address this?

https://bugzilla.mozilla.org/show_bug.cgi?id=797815

Getting OCSP changes into the tree has been difficult because all new code needs automated tests and there was no way to sign OCSP responses in NSS. This is being addressed so it may unblock a number of OCSP changes.

Updating the description. We have decided that ipa-ca.$DOMAIN shall hold a list of A records instead of one CNAMEs. As this URI will be the only one in the FreeIPA certificates (see #3522), it will allow splitting the load between FreeIPA CAs to some extent.

master:[[BR]]

fe00788 Delete DNS records in ipa-ca on ipa-csreplica-manage del.[[BR]]
f684c6d Use A/AAAA records instead of CNAME records in ipa-ca.[[BR]]

NOTE: ipa-ca.DOMAIN CNAMEs are replaced with A/AAAA if and only if they all point to IPA masters, otherwise a warning is printed.

ipa-3-1:[[BR]]
52a9b23 Delete DNS records in ipa-ca on ipa-csreplica-manage del.[[BR]]
58cb8f4 Use A/AAAA records instead of CNAME records in ipa-ca.[[BR]]