Third-party certificate trust flags are reset after installing an external CA into IdM
The "ipa-ca-install --external-ca" command, used to install an external certificate authority (CA) into an existing Identity Management (IdM) domain, generates a certificate signing request (CSR) that the user must submit to the external CA.
When using a previously installed third-party certificate to sign the CSR, the third-party certificate trust flags in the NSS database are reset. Consequently, the certificate is no longer marked as trusted. In addition, checks performed by the `mod_nss` module fail, and the *httpd* service fails to start. The CA installation fails with the following message in this situation:
CA failed to start after 300 seconds
As a workaround, after this message appears, reset the third-party certificate flags to their previous state and restart *httpd*. For example, if the `ca1` certificate previously had the `C,,` trust flags:
# certutil -d /etc/httpd/alias -n 'ca1' -M -t C,,
# systemctl restart httpd.service
This restores the system to the correct state.
Description of problem:
While converting CA-less to CA-FULL IPA server, CA fails to start after ipa-ca-install installation.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create Self-signed CA certificate and server certificates
2. # ipa-server-install --http_pkcs12 server.p12 --http_pin Secret123 --dirsrv_pkcs12 server.p12 --dirsrv_pin Secret123 --root-ca-file ca.crt --ip-address 10.10.10.1 -r testrelm.test -p 'Secret123' -a 'Secret123' --setup-dns --forwarder 10.10.10.89 -U
3. # ipa-ca-install --external-ca
4. Get IPA CSR signed using external CA
# certutil -C -i /root/ipa.csr -o ipa.crt -c "ca1" -d nssdb -a
5. # /usr/sbin/ipa-ca-install --external-cert-file=ipa.crt --external-cert-file=ca.crt <= This command fails to start CA server
CA did not start even after waiting for 300 seconds.
CA should start and installation should be successful.
Please see installation logs and console.log in attachments.
This happens only if a previously installed 3rd party CA certificate is used to sign the IPA CA certificate.
This is a bug in both pki-core and IPA. The pki-core part is tracked in bug 1325756. In IPA, we need to fix ipa-ca-install to set correct trust flags on all the involved CA certificates.
Jan, am I right that if we add the flag, then it will work? I.e. that fixing PKI 1325756 is not in fact required(as was my previous conviction)?
If so I'd rather fix this sooner.
We need to set
The described workaround no longer works with newer versions of pki. There seems to be a bug that prevents this workaround:
FYI, PKI ticket #2451 was closed since it's not a PKI issue. The error seems to be happening in httpd/mod_nss.
Or he is starting the wrong service to test the workaround.
1. Install CA-less ipa-server
[root@master ~]# ipa-server-install --http_pkcs12 server.p12 --http_pin XXX --dirsrv_pkcs12 server.p12 --dirsrv_pin XXX --no-pkinit --ip-address $(ip addr|grep "global"|cut -d " " -f6|cut -d "/" -f1|head -n 1) -r testrelm.test -p 'XXX' -a 'XXX' --setup-dns --forwarder 192.168.222.1 -U
2. Install CA with external option
[root@master ~]# ipa-ca-install --external-ca
3. Get "ipa.csr" signed using external CA
[root@master ~]# certutil -C -i ipa.csr -o ipa.crt -c "ca1" -d nssdb -a
4. Complete CA install
[root@master ~]# ipa-ca-install --external-cert-file=ipa.crt --external-cert-file=ca1.pem
Directory Manager (existing master) password:
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
[1/29]: configuring certificate server instance
[2/29]: exporting Dogtag certificate store pin
[3/29]: stopping certificate server instance to update CS.cfg
[4/29]: backing up CS.cfg
[5/29]: disabling nonces
[6/29]: set up CRL publishing
[7/29]: enable PKIX certificate path discovery and validation
[8/29]: starting certificate server instance
[9/29]: configure certmonger for renewals
[10/29]: requesting RA certificate from CA
[11/29]: setting up signing cert profile
[12/29]: setting audit signing renewal to 2 years
[13/29]: restarting certificate server
[14/29]: publishing the CA certificate
[15/29]: adding RA agent as a trusted user
[16/29]: authorizing RA to modify profiles
[17/29]: authorizing RA to manage lightweight CAs
[18/29]: Ensure lightweight CAs container exists
[19/29]: configure certificate renewals
[20/29]: configure Server-Cert certificate renewal
[21/29]: Configure HTTP to proxy connections
[22/29]: restarting certificate server
[23/29]: migrating certificate profiles to LDAP
[24/29]: importing IPA certificate profiles
[25/29]: adding default CA ACL
[26/29]: adding 'ipa' CA entry
[27/29]: updating IPA configuration
[28/29]: enabling CA instance
[29/29]: configuring certmonger renewal for lightweight CAs
Done configuring certificate server (pki-tomcatd).
Updating DNS system records
[root@master ~]# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
ntpd Service: RUNNING
pki-tomcatd Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful
[root@master ~]# certutil -L -d /etc/httpd/alias/
Certificate Nickname Trust Attributes
Changing status to Verified as per comment24
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.