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
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.3
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: Michal Reznik
Aneta Šteflová Petrová
URL:
Whiteboard:
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)
Environment:
Last Closed: 2017-08-01 09:37:23 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
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):
ipa-server-4.2.0-15.el7_2.10.x86_64

How reproducible:
100%

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 

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:
https://fedorahosted.org/freeipa/ticket/5791
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 
  ca.cert.signing.certusage=AnyCA
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:
https://fedorahosted.org/pki/ticket/2451
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 19 Martin Bašti 2016-09-19 15:59:40 UTC 
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/2bc70a5d5f5eb953969e7341179c5083c147221a
ipa-4-3:
https://fedorahosted.org/freeipa/changeset/b3e57f789ef7f697f8cc68f180dc8ce292954ed4
Comment 20 Martin Bašti 2016-09-21 13:42:49 UTC 
Fixed upstream
ipa-4-4:
https://fedorahosted.org/freeipa/changeset/741f2e4e7a6d3fddf39fec42ea9b49b753af9cf4
ipa-4-2:
https://fedorahosted.org/freeipa/changeset/202ab8719e3c3a2dfd7fa82d84162954751405a3
Comment 24 Michal Reznik 2017-05-17 14:43:01 UTC 
Verified on:

ipa-server-4.5.0-9.el7.x86_64
pki-base-10.4.1-3.el7.noarch
pki-ca-10.4.1-3.el7.noarch

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
                                                             SSL,S/MIME,JAR/XPI

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.

https://access.redhat.com/errata/RHBA-2017:2304
Note You need to log in before you can comment on or make changes to this bug.