RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1341249 - Subsequent external CA installation fails
Summary: Subsequent external CA installation fails
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: Kaleem
URL:
Whiteboard:
Depends On:
Blocks: 1295338
TreeView+ depends on / blocked
 
Reported: 2016-05-31 14:30 UTC by Marc Muehlfeld
Modified: 2016-11-04 05:54 UTC (History)
5 users (show)

Fixed In Version: ipa-4.4.0-6.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-04 05:54:33 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Logs from installing the external CA (49.97 KB, application/x-gzip)
2016-05-31 14:30 UTC, Marc Muehlfeld 		no flags Details
selftests.log (2.27 KB, text/plain)
2016-06-01 06:40 UTC, Marc Muehlfeld 		no flags Details
certificates (3.37 KB, application/x-bzip)
2016-06-01 08:16 UTC, Marc Muehlfeld 		no flags Details
console output with verification steps (14.63 KB, text/plain)
2016-09-09 15:22 UTC, Kaleem 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2404 0 normal SHIPPED_LIVE ipa bug fix and enhancement update 2016-11-03 13:56:18 UTC

Description Marc Muehlfeld 2016-05-31 14:30:05 UTC 
Created attachment 1163261 [details]
Logs from installing the external CA

Description of problem:
When trying to subsequently install an external CA on a CA-less IdM installation, the setup fails, because the CA status can't be checked after restarting pki-tomcatd.

In the ipaserver-ca-install.log logfile you can see that the URL https://vm-01.idm.example.com:8443/ca/admin/ca/getStatus returns an 404 error (Not found).



Version-Release number of selected component (if applicable):
ipa-server-4.2.0-15.el7_2.15.x86_64



How reproducible:
Always.



Steps to Reproduce:
1. Set up an IdM master without CA
2. Run "ipa-ca-install --external-ca"
3. Submit the CSR to the external CA and copy the issued certificate + CA certificate to the IdM host.
4. Continue with the CA Setup
  ipa-ca-install --external-cert-file=/root/vm-01.idm.example.com.crt --external-cert-file=/root/ca.crt



Actual results:
When continuing with the second step of the CA setup, ipa-ca-install fails:
...
  [13/27]: restarting certificate server
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to restart the Dogtag instance.See the installation log for details.



Expected results:
ipa-ca-install should finish successfully.
Comment 2 Martin Bašti 2016-06-01 04:16:04 UTC 
Additional info:

It looks like the CA subsystem is disabled, what is the reason why IPA cannot connect to the port

máj 31 12:14:08 vm-01.idm.example.com server[2546]: INFO: Starting ProtocolHandler ["http-bio-8443"]
máj 31 12:14:08 vm-01.idm.example.com server[2546]: May 31, 2016 12:14:08 PM org.apache.coyote.AbstractProtocol start
máj 31 12:14:08 vm-01.idm.example.com server[2546]: INFO: Starting ProtocolHandler ["ajp-bio-127.0.0.1-8009"]
máj 31 12:14:08 vm-01.idm.example.com server[2546]: PKIListener: org.apache.catalina.core.StandardServer[after_start]
máj 31 12:14:08 vm-01.idm.example.com server[2546]: PKIListener: Subsystem CA is disabled.
máj 31 12:14:08 vm-01.idm.example.com server[2546]: PKIListener: Check /var/log/pki/pki-tomcat/ca/selftests.log for possible errors.
máj 31 12:14:08 vm-01.idm.example.com server[2546]: PKIListener: To enable the subsystem:
máj 31 12:14:08 vm-01.idm.example.com server[2546]: PKIListener:   pki-server subsystem-enable -i pki-tomcat ca
máj 31 12:14:08 vm-01.idm.example.com server[2546]: May 31, 2016 12:14:08 PM org.apache.catalina.startup.Catalina start
máj 31 12:14:08 vm-01.idm.example.com server[2546]: INFO: Server startup in 4956 ms
Comment 3 Martin Bašti 2016-06-01 04:17:54 UTC 
Marc is possible to get content of /var/log/pki/pki-tomcat/ca/selftests.log file?
Comment 4 Marc Muehlfeld 2016-06-01 06:40:30 UTC 
Created attachment 1163495 [details]
selftests.log
Comment 5 Petr Vobornik 2016-06-01 07:57:07 UTC 
PKI debug log shows that most of PKI system certs are not valid.

I'd be interested in output of:
 # getcert list

the debug log part:
[31/May/2016:16:14:04][localhost-startStop-1]: CertUtils: verifySystemCerts() cert tag=signing
[31/May/2016:16:14:04][localhost-startStop-1]: CertUtils: verifySystemCertByTag(signing)
[31/May/2016:16:14:04][localhost-startStop-1]: CertUtils: verifySystemCertByNickname(caSigningCert cert-pki-ca,SSLCA)
[31/May/2016:16:14:04][localhost-startStop-1]: CertUtils: verifySystemCertByNickname(): calling isCertValid()
[31/May/2016:16:14:04][localhost-startStop-1]: CertUtils: verifySystemCertByNickname() failed: caSigningCert cert-pki-ca
[31/May/2016:16:14:04][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Failure][CertNickName=caSigningCert cert-pki-ca] CIMC certificate verification

[31/May/2016:16:14:04][localhost-startStop-1]: CertUtils: verifySystemCerts() cert tag=ocsp_signing
[31/May/2016:16:14:04][localhost-startStop-1]: CertUtils: verifySystemCertByTag(ocsp_signing)
[31/May/2016:16:14:04][localhost-startStop-1]: CertUtils: verifySystemCertByNickname(ocspSigningCert cert-pki-ca,StatusResponder)
[31/May/2016:16:14:04][localhost-startStop-1]: CertUtils: verifySystemCertByNickname(): calling isCertValid()
[31/May/2016:16:14:04][localhost-startStop-1]: CertUtils: verifySystemCertByNickname() failed: ocspSigningCert cert-pki-ca
[31/May/2016:16:14:04][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Failure][CertNickName=ocspSigningCert cert-pki-ca] CIMC certificate verification

[31/May/2016:16:14:04][localhost-startStop-1]: CertUtils: verifySystemCerts() cert tag=sslserver
[31/May/2016:16:14:04][localhost-startStop-1]: CertUtils: verifySystemCertByTag(sslserver)
[31/May/2016:16:14:04][localhost-startStop-1]: CertUtils: verifySystemCertByNickname(Server-Cert cert-pki-ca,SSLServer)
[31/May/2016:16:14:04][localhost-startStop-1]: CertUtils: verifySystemCertByNickname(): calling isCertValid()
[31/May/2016:16:14:04][localhost-startStop-1]: CertUtils: verifySystemCertByNickname() failed: Server-Cert cert-pki-ca
[31/May/2016:16:14:04][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Failure][CertNickName=Server-Cert cert-pki-ca] CIMC certificate verification
Comment 6 Marc Muehlfeld 2016-06-01 08:16:26 UTC 
Created attachment 1163508 [details]
certificates

# getcert list
Number of certificates and requests being tracked: 0.


I've attached the certificate and the CA certificate I used. It's a self-created CA with Easy-RSA, so it's not a problem to attach them here.
Comment 7 Petr Vobornik 2016-06-02 14:35:59 UTC 
Maybe a dumb question. The vm-01.idm.example.com.crt from comment 6 was created and used on 2016-05-31 as the bug report or later with different run on 2016-06-01?
Comment 8 Marc Muehlfeld 2016-06-02 14:53:27 UTC 
(In reply to Petr Vobornik from comment #7)
> Maybe a dumb question. The vm-01.idm.example.com.crt from comment 6 was
> created and used on 2016-05-31 as the bug report or later with different run
> on 2016-06-01?

I had to destroy and the IdM installation on this VM in the meantime to do some other testings. That's why the certificates I attached later have a newer date. Sorry if this caused confusion.
Comment 9 Petr Vobornik 2016-06-07 11:34:45 UTC 
According to jcholast the issue is that the provided cert is not a CA cert.

It indicates a bug in validation - either in IPA or pkispawn.

Endi, is it something that PKI should already checks(i.e. is there a regression)?
Comment 10 Endi Sukma Dewata 2016-06-11 02:16:45 UTC 
I believe PKI is validating all system certificates during startup as shown in comment #5, but I don't see a code that validates the external CA certificate. I'm not sure whether NSS is validating the entire certificate chain implicitly. Please feel free to open a ticket if the chain is not being validated properly, and please also provide the instruction to reproduce the problem (i.e. how to generate the certificates using Easy-RSA). Thanks.
Comment 11 Petr Vobornik 2016-06-17 15:26:06 UTC 
Marc, could you share the exact commands how you generate the certs?
Comment 13 Petr Vobornik 2016-06-22 16:57:54 UTC 
Per, triage on Jul 20, IPA should also validate the flags. It needs to be investigated why it failed.
Comment 14 Jan Cholasta 2016-08-04 07:14:48 UTC 
I was able to reproduce this and found a bug in IPA in code which loads and validates the certificates.

(But pkispawn should still validate them anyway, see bug 1224623.)
Comment 15 Jan Cholasta 2016-08-04 07:16:45 UTC 
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/6166
Comment 16 Jan Cholasta 2016-08-04 08:43:00 UTC 
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/a42b456b91cb345e977c6f0febf5c30f15a954d3
ipa-4-3:
https://fedorahosted.org/freeipa/changeset/44401d26c29e35d38bc94a7a87b9f2dd205e0643
Comment 19 Kaleem 2016-09-09 15:21:09 UTC 
Verified.

IPA Version:
============
[root@dhcp207-130 ~]# rpm -q ipa-server
ipa-server-4.4.0-10.el7.x86_64
[root@dhcp207-130 ~]# 

Please find attached file for console output of verification steps.
Comment 20 Kaleem 2016-09-09 15:22:09 UTC 
Created attachment 1199519 [details]
console output with verification steps
Comment 22 errata-xmlrpc 2016-11-04 05:54:33 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://rhn.redhat.com/errata/RHBA-2016-2404.html
Note You need to log in before you can comment on or make changes to this bug.