Bug 1318616 - CA fails to start after doing ipa-ca-install --external-ca
Summary: CA fails to start after doing ipa-ca-install --external-ca
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.3
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: Michal Reznik
Aneta Šteflová Petrová
Depends On: 1325756
Blocks: 1389249
TreeView+ depends on / blocked
Reported: 2016-03-17 11:15 UTC by Abhijeet Kasurde
Modified: 2017-08-01 09:37 UTC (History)
10 users (show)

Fixed In Version: ipa-4.4.0-13.el7
Doc Type: Known Issue
Doc Text:
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.
Clone Of:
: 1389249 (view as bug list)
Last Closed: 2017-08-01 09:37:23 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2304 0 normal SHIPPED_LIVE ipa bug fix and enhancement update 2017-08-01 12:41:35 UTC

Description Abhijeet Kasurde 2016-03-17 11:15:31 UTC
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):

How reproducible:

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 -r testrelm.test -p 'Secret123' -a 'Secret123' --setup-dns --forwarder -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 

Actual results:
CA did not start even after waiting for 300 seconds.

Expected results:
CA should start and installation should be successful.

Additional info:
Please see installation logs and console.log in attachments.

Comment 3 Petr Vobornik 2016-04-08 08:36:48 UTC
Upstream ticket:

Comment 4 Jan Cholasta 2016-04-11 06:26:35 UTC
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.

Comment 7 Petr Vobornik 2016-08-25 14:42:04 UTC
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.

Comment 8 Petr Vobornik 2016-08-29 11:10:58 UTC
We need to set 
in CS.cfg

Comment 11 Tomas Krizek 2016-09-01 12:38:18 UTC
The described workaround no longer works with newer versions of pki. There seems to be a bug that prevents this workaround:

Comment 14 Endi Sukma Dewata 2016-09-08 13:54:03 UTC
FYI, PKI ticket #2451 was closed since it's not a PKI issue. The error seems to be happening in httpd/mod_nss.

Comment 15 Rob Crittenden 2016-09-08 14:02:07 UTC
Or he is starting the wrong service to test the workaround.

Comment 24 Michal Reznik 2017-05-17 14:43:01 UTC
Verified on:


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 -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

ca1/server                                                   u,u,u
ca1                                                          C,,

Comment 25 Kaleem 2017-05-18 05:33:14 UTC
Changing status to Verified as per comment24

Comment 26 errata-xmlrpc 2017-08-01 09:37:23 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.