Bug 1318616

Summary: CA fails to start after doing ipa-ca-install --external-ca
Product: Red Hat Enterprise Linux 7 Reporter: Abhijeet Kasurde <akasurde>
Component: ipaAssignee: IPA Maintainers <ipa-maint>
Status: CLOSED ERRATA QA Contact: Michal Reznik <mreznik>
Severity: unspecified Docs Contact: Aneta Šteflová Petrová <apetrova>
Priority: high    
Version: 7.3CC: edewata, ipa-qe, jcholast, ksiddiqu, mbasti, nsoman, pvoborni, rcritten, tkrizek, tscherf
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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.
Story Points: ---
Clone Of:
: 1389249 (view as bug list) Environment:
Last Closed: 2017-08-01 09:37:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1325756    
Bug Blocks: 1389249    

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