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 1381084 - KRA installation failed against externally-signed CA with partial certificate chain
Summary: KRA installation failed against externally-signed CA with partial certificate...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pki-core
Version: 7.3
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: RHCS Maintainers
QA Contact: Asha Akkiangady
Petr Bokoc
URL:
Whiteboard:
Depends On:
Blocks: 1390324
TreeView+ depends on / blocked
 
Reported: 2016-10-02 21:03 UTC by Roshni
Modified: 2020-10-04 21:16 UTC (History)
10 users (show)

Fixed In Version: pki-core-10.4.0-1.el7
Doc Type: Bug Fix
Doc Text:
KRA installation no longer fails when connecting to an intermediate CA with an incomplete certificate chain Previously, installing a Key Recovery Authority (KRA) subsystem failed with an `UNKNOWN_ISSUER` error if the KRA attempted to connect to an intermediate CA that had a trusted CA certificate but did not have the root CA certificate. With this update, KRA installation ignores the error and completes successfully.
Clone Of:
: 1390324 (view as bug list)
Environment:
Last Closed: 2017-08-01 22:46:01 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github dogtagpki pki issues 2617 0 None None None 2020-10-04 21:16:41 UTC
Red Hat Product Errata RHBA-2017:2110 0 normal SHIPPED_LIVE pki-core bug fix and enhancement update 2017-08-01 19:36:59 UTC

Description Roshni 2016-10-02 21:03:15 UTC 
Description of problem:
KRA installation with externally signed CA fails if the CA certificate chain p12 is not specified in the CA config

Version-Release number of selected component (if applicable):
pki-ca-10.3.3-10.el7.noarch

How reproducible:
always

Steps to Reproduce:
1. Root CA config
[DEFAULT]
pki_instance_name = pki-rootCA
pki_admin_password = Secret123
pki_hostname = beast.idmqe.lab.eng.bos.redhat.com
pki_security_domain_password = Secret123
pki_client_dir = /opt/topology-CA
pki_client_pkcs12_password = Secret123
pki_ds_password = Secret123
pki_ds_ldap_port = 389
pki_token_password=Secret123

[CA]
pki_import_admin_cert = False
pki_ds_hostname = beast.idmqe.lab.eng.bos.redhat.com
pki_admin_nickname = PKI CA Administrator for Example.Org

2. First externally signed CA in the chain (topCA)
Step 1
[DEFAULT]
pki_instance_name = pki-topCA
pki_admin_password = Secret123
pki_hostname = spider.idmqe.lab.eng.bos.redhat.com
pki_security_domain_password = Secret123
pki_client_dir = /opt/topology-CA
pki_client_pkcs12_password = Secret123
pki_ds_password = Secret123
pki_ds_ldap_port = 389
pki_token_password=Secret123
pki_client_database_password=Secret123

[CA]
pki_import_admin_cert = False
pki_ds_hostname = spider.idmqe.lab.eng.bos.redhat.com
pki_admin_nickname = PKI CA Administrator for Example.Org
pki_external=True
pki_external_csr_path=/tmp/ca_signing.csr

Step 2

[DEFAULT]
pki_instance_name = pki-topCA
pki_admin_password = Secret123
pki_hostname = spider.idmqe.lab.eng.bos.redhat.com
pki_security_domain_password = Secret123
pki_client_dir = /opt/topology-CA
pki_client_pkcs12_password = Secret123
pki_ds_password = Secret123
pki_ds_ldap_port = 389
pki_token_password=Secret123
pki_client_database_password=Secret123

[CA]
pki_import_admin_cert = False
pki_ds_hostname = spider.idmqe.lab.eng.bos.redhat.com
pki_admin_nickname = PKI CA Administrator for Example.Org
pki_external=True
pki_external_ca_cert_path=/tmp/ca_signing.crt
pki_external_ca_cert_chain_path=/tmp/ca_cert_chain.cert
pki_external_step_two=True

3. second externally signed CA

Step 1:

[root@cisco-b200m1-04 ~]# cat ca.cfg 
[DEFAULT]
pki_instance_name = pki-sdCA
pki_admin_password = Secret123
pki_hostname = cisco-b200m1-04.rhts.eng.bos.redhat.com
pki_security_domain_password = Secret123
pki_client_dir = /opt/topology-CA
pki_client_pkcs12_password = Secret123
pki_ds_password = Secret123
pki_ds_ldap_port = 389
pki_token_password=Secret123

[CA]
pki_import_admin_cert = False
pki_ds_hostname = cisco-b200m1-04.rhts.eng.bos.redhat.com
pki_admin_nickname = PKI CA Administrator for Example.Org
pki_external=True
pki_external_csr_path=/tmp/ca_signing.csr
[root@cisco-b200m1-04 ~]# cat ca-step2.cfg 

Step 2
[DEFAULT]
pki_instance_name = pki-sdCA
pki_admin_password = Secret123
pki_hostname = cisco-b200m1-04.rhts.eng.bos.redhat.com
pki_security_domain_password = Secret123
pki_client_dir = /opt/topology-CA
pki_client_pkcs12_password = Secret123
pki_ds_password = Secret123
pki_ds_ldap_port = 389
pki_token_password=Secret123
pki_client_database_password=Secret123

[CA]
pki_import_admin_cert = False
pki_ds_hostname = cisco-b200m1-04.rhts.eng.bos.redhat.com
pki_admin_nickname = PKI CA Administrator for Example.Org
pki_external=True
pki_external_ca_cert_path=/tmp/ca_signing.crt
pki_external_ca_cert_chain_path=/tmp/ca_cert_chain.cert
pki_external_step_two=True

KRA config

[root@cisco-b200m1-04 ~]# cat kra.cfg 
[DEFAULT]
pki_instance_name = pki-kra
pki_https_port = 21443
pki_http_port = 21080
pki_admin_password = Secret123
pki_hostname = cisco-b200m1-04.rhts.eng.bos.redhat.com
pki_security_domain_hostname = cisco-b200m1-04.rhts.eng.bos.redhat.com
pki_security_domain_https_port = 8443
pki_security_domain_password = Secret123
pki_client_dir = /opt/topology-KRA
pki_client_pkcs12_password = Secret123
pki_ds_password = Secret123
pki_ds_ldap_port = 5389
pki_client_database_password = Secret123
pki_token_password=Secret123

[Tomcat]
pki_ajp_port = 21009
pki_tomcat_server_port = 21005

[KRA]
pki_import_admin_cert = False
pki_ds_hostname = cisco-b200m1-04.rhts.eng.bos.redhat.com
pki_admin_nickname = PKI KRA Administrator for Example.Org


[root@cisco-b200m1-04 ~]# certutil -L -d /var/lib/pki/pki-sdCA/alias/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

caSigningCert External CA                                    CT,C,C
ocspSigningCert cert-pki-sdCA CA                             u,u,u
subsystemCert cert-pki-sdCA                                  u,u,u
caSigningCert cert-pki-sdCA CA                               CTu,Cu,Cu
Server-Cert cert-pki-sdCA                                    u,u,u
auditSigningCert cert-pki-sdCA CA                            u,u,Pu

Actual results:
KRA installation fails 

Expected results:
KRA installation should succeed

Additional info:
KRA installation was succesful after executing the following commands on rootCA

pki-server ca-cert-chain-export --pkcs12-file pki-server.p12 --pkcs12-password Secret123

and adding the following to KRA's config file

pki_server_pkcs12_path=pki-server.p12
pki_server_pkcs12_password=Secret123

The following is the error in the log messages

[30/Sep/2016:13:51:53][http-bio-21443-exec-3]: SystemConfigService: request: ConfigurationRequest [pin=XXXX, token=Internal Key Storage Token, tokenPassword=XXXX, securityDomainType=existingdomain, securityDomainUri=https://cisco-b200m1-04.rhts.eng.bos.redhat.com:8443, securityDomainName=null, securityDomainUser=caadmin, securityDomainPassword=XXXX, isClone=false, cloneUri=null, subsystemName=KRA cisco-b200m1-04.rhts.eng.bos.redhat.com 21443, p12File=null, p12Password=XXXX, hierarchy=null, dsHost=cisco-b200m1-04.rhts.eng.bos.redhat.com, dsPort=5389, baseDN=o=pki-kra-KRA, bindDN=cn=Directory Manager, bindpwd=XXXX, database=pki-kra-KRA, secureConn=false, removeData=true, replicateSchema=null, masterReplicationPort=null, cloneReplicationPort=null, replicationSecurity=null, systemCertsImported=false, systemCerts=[com.netscape.certsrv.system.SystemCertData@75339348, com.netscape.certsrv.system.SystemCertData@15e02ca6, com.netscape.certsrv.system.SystemCertData@42b0c9be, com.netscape.certsrv.system.SystemCertData@22b5d29f, com.netscape.certsrv.system.SystemCertData@4b75ac52], issuingCA=https://cisco-b200m1-04.rhts.eng.bos.redhat.com:8443, backupKeys=false, backupPassword=XXXX, adminCertRequestType=pkcs10, adminSubjectDN=cn=PKI Administrator,e=kraadmin.bos.redhat.com,ou=pki-kra,o=rhts.eng.bos.redhat.com Security Domain, adminName=kraadmin, adminProfileID=caAdminCert, adminCert=null, importAdminCert=false, generateServerCert=true, external=false, standAlone=false, stepTwo=false, authdbBaseDN=null, authdbHost=null, authdbPort=null, authdbSecureConn=null, caUri=null, kraUri=null, tksUri=null, enableServerSideKeyGen=null, importSharedSecret=null, generateSubsystemCert=true, sharedDB=true, sharedDBUserDN=uid=pkidbuser,ou=people,o=pki-kra-CA, createNewDB=true, setupReplication=null, subordinateSecurityDomainName=null, reindexData=null, startingCrlNumber=null]
[30/Sep/2016:13:51:53][http-bio-21443-exec-3]: === Token Authentication ===
[30/Sep/2016:13:51:53][http-bio-21443-exec-3]: === Security Domain Configuration ===
[30/Sep/2016:13:51:53][http-bio-21443-exec-3]: Joining existing security domain
[30/Sep/2016:13:51:53][http-bio-21443-exec-3]: Resolving security domain URL https://cisco-b200m1-04.rhts.eng.bos.redhat.com:8443
[30/Sep/2016:13:51:53][http-bio-21443-exec-3]: Getting security domain cert chain
[30/Sep/2016:13:51:53][http-bio-21443-exec-3]: ConfigurationUtils.importCertChain()
[30/Sep/2016:13:51:53][http-bio-21443-exec-3]: ConfigurationUtils: GET https://cisco-b200m1-04.rhts.eng.bos.redhat.com:8443/ca/admin/ca/getCertChain
[30/Sep/2016:13:51:54][http-bio-21443-exec-3]: Server certificate:
[30/Sep/2016:13:51:54][http-bio-21443-exec-3]:  - subject: CN=cisco-b200m1-04.rhts.eng.bos.redhat.com,OU=pki-sdCA,O=rhts.eng.bos.redhat.com Security Domain
[30/Sep/2016:13:51:54][http-bio-21443-exec-3]:  - issuer: CN=CA Signing Certificate,OU=pki-sdCA,O=rhts.eng.bos.redhat.com Security Domain
[30/Sep/2016:13:51:54][http-bio-21443-exec-3]: ERROR: UNKNOWN_ISSUER
[30/Sep/2016:13:51:54][http-bio-21443-exec-3]: Server certificate:
[30/Sep/2016:13:51:54][http-bio-21443-exec-3]:  - subject: CN=cisco-b200m1-04.rhts.eng.bos.redhat.com,OU=pki-sdCA,O=rhts.eng.bos.redhat.com Security Domain
[30/Sep/2016:13:51:54][http-bio-21443-exec-3]:  - issuer: CN=CA Signing Certificate,OU=pki-sdCA,O=rhts.eng.bos.redhat.com Security Domain
[30/Sep/2016:13:51:54][http-bio-21443-exec-3]: ERROR: UNKNOWN_ISSUER
javax.ws.rs.ProcessingException: Unable to invoke request
	at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:287)
	at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:407)
	at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:442)
	at org.jboss.resteasy.client.jaxrs.internal.ClientInvocationBuilder.get(ClientInvocationBuilder.java:165)
	at com.netscape.certsrv.client.PKIConnection.get(PKIConnection.java:467)
	at com.netscape.cms.servlet.csadmin.ConfigurationUtils.get(ConfigurationUtils.java:237)
	at com.netscape.cms.servlet.csadmin.ConfigurationUtils.importCertChain(ConfigurationUtils.java:266)
	at org.dogtagpki.server.rest.SystemConfigService.logIntoSecurityDomain(SystemConfigService.java:965)
	at org.dogtagpki.server.rest.SystemConfigService.configureSecurityDomain(SystemConfigService.java:922)
	at org.dogtagpki.server.rest.SystemConfigService.configure(SystemConfigService.java:160)
	at org.dogtagpki.server.rest.SystemConfigService.configure(SystemConfigService.java:121)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:549)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:175)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186)
	at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:288)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:285)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:549)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:320)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:260)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:436)
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: SocketException cannot write on socket
	at org.mozilla.jss.ssl.SSLSocket.write(SSLSocket.java:1099)
	at org.mozilla.jss.ssl.SSLOutputStream.write(SSLOutputStream.java:56)
	at org.apache.http.impl.io.AbstractSessionOutputBuffer.flushBuffer(AbstractSessionOutputBuffer.java:147)
	at org.apache.http.impl.io.AbstractSessionOutputBuffer.flush(AbstractSessionOutputBuffer.java:154)
	at org.apache.http.impl.AbstractHttpClientConnection.doFlush(AbstractHttpClientConnection.java:278)
	at org.apache.http.impl.AbstractHttpClientConnection.flush(AbstractHttpClientConnection.java:283)
	at org.apache.http.impl.conn.ManagedClientConnectionImpl.flush(ManagedClientConnectionImpl.java:175)
	at org.apache.http.protocol.HttpRequestExecutor.doSendRequest(HttpRequestExecutor.java:260)
	at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
	at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
	at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
	at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
	at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
	at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:283)
	... 72 more
Comment 2 Endi Sukma Dewata 2016-10-03 19:39:52 UTC 
Roshni,

When installing the 3rd-level CA (sdCA) it looks like only one of the external CA certificates was specified, so the certificate chain is incomplete:

pki_external_ca_cert_chain_path=/tmp/ca_cert_chain.cert

Which external CA certificate was specified there?

It's possible that for a proper CA installation the complete certificate chain is required. Could you try again but specify a PKCS #7 file containing both the 1st-level and 2nd-level CA certificates in the above parameter? Then try installing KRA again without the PKCS #12 file.

Regardless, the 3rd-level CA installation with incomplete certificate chain probably should have failed in the first place.

Thanks.
Comment 3 Endi Sukma Dewata 2016-10-03 22:56:51 UTC 
The problem can also be reproduced with these steps:

1. Create an NSS database and generate 1st-level CA cert.
2. Create another NSS database and generate a CSR for 2nd-level CA cert.
3. Sign the CSR with 1st-level CA cert to generate 2nd-level CA cert.
4. Import the 2nd-level CA cert into the 2nd NSS database.
5. Run PKI CA installation step 1.
6. Sign the CSR with 2nd-level CA cert to generate the 3rd-level CA cert for PKI CA.
7. Run PKI CA installation step 2 with pki_external_ca_cert_chain_path pointing to 2nd-level CA cert only.
8. Install PKI KRA pointing to PKI CA.

Here KRA installation will fail with the same error.

If the pki_external_ca_cert_chain_path in step 7 is changed to point to a PKCS #7 file containing both 1st-level and 2nd-level CA certificates, the KRA installation will work just fine.

As mentioned earlier, the issue is not in the KRA installation, but the CA installation in step 7 should have failed if the certificate chain is incomplete. The certificate chain is validated using NSS, so there might be an issue in NSS itself.
Comment 4 Matthew Harmsen 2016-10-04 00:27:31 UTC 
Upstream ticket:
https://fedorahosted.org/pki/ticket/2497
Comment 6 Endi Sukma Dewata 2016-10-04 01:04:50 UTC 
The problem does not happen on sub CA (i.e. level 2) since without the root CA the sub CA installation will fail.

The problem affects CA level 3 or above, but it only happens if the certificate chain is incomplete (i.e. negative case?). If the certificate chain is complete the problem does not happen.
Comment 7 Endi Sukma Dewata 2016-10-04 01:08:36 UTC 
The issue can be simplified further with these steps:

1. Create an NSS database.
2. Create 3 CA certificates where one is signed by the previous one.
3. Validate the 2nd- and 3rd-level CA certificates:

$ certutil -V -d nssdb -n "2nd-level CA" -u L
certutil: certificate is valid
$ certutil -V -d nssdb -n "3rd-level CA" -u L
certutil: certificate is valid

4. Remove the 1st-level CA certificate.
5. Run the same validations again:

$ certutil -V -d nssdb -n "2nd-level CA" -u L
certutil: certificate is invalid: Peer's Certificate issuer is not recognized.
$ certutil -V -d nssdb -n "3rd-level CA" -u L
certutil: certificate is valid

Notice that after removing the 1st-level CA certificate the 2nd-level CA certificate becomes invalid but the 3rd-level CA certificate is still valid.

Christina, are these certificate validations correct? Should a 3rd-level CA be able to function properly without the 1st-level CA certificate?
Comment 8 Endi Sukma Dewata 2016-10-04 20:15:28 UTC 
Per discussion with Christina, to avoid KRA installation issues we are considering to modify the installation tool to require the admin to provide the complete certificate chain during CA installation with externally-signed CA certificate.

Kai, Petr, would this be a reasonable requirement? Please take a look at comment #7. Thanks.
Comment 9 Kai Engert (:kaie) (inactive account) 2016-10-04 20:56:23 UTC 
I don't understand the request. Could you please explain in more detail, what you're asking me to do? Thanks.
Comment 10 Matthew Harmsen 2016-10-04 21:12:11 UTC 
Per PKI Bug Council Meeting of 10/04/2016: 7.4
Comment 11 Endi Sukma Dewata 2016-10-05 00:38:58 UTC 
Kai, here's the situation. Suppose we have 3 CA certificates forming a chain. The last CA certificate is used to issue various other certificates.

My question is, in order to validate those certificates properly do we need to store and trust all 3 CA certificates in the NSS database (i.e. complete chain is always needed)? Or if one of the CA certificates is already trusted, the parents of that CA certificate no longer needs to present in the NSS database (i.e. partial chain is sufficient)?

Currently Dogtag allows installing a CA server with just a partial chain, but that apparently causes a problem when another system tries to interact with it. We're wondering if it's supposed to work with partial chain or whether the CA server should have been installed with the complete chain in the first place.
Comment 12 Petr Vobornik 2016-10-05 08:07:01 UTC 
The situation looks very similar to bug 1325756, comment 15
Comment 13 Kai Engert (:kaie) (inactive account) 2016-10-05 21:22:07 UTC 
I think you're describing:

- root CA (self-signed, same subject and issuer names)

- intermediate CA 1 (issued by root CA)

- intermediate CA 2 (issued by intermediate CA 2)

- end entity certs (issued by intermediate CA 2


Usually, only the topmost root is explicitly marked trusted. I think that isn't a property of NSS in particular, but with PKI in general.

It's not necessary to mark the intermediates as trusted.

However, it's necessary that NSS "knows" about the intermediates.

If NSS only sees the root CA marked as trusted, and an end entity cert, it cannot find the chain.

So, the usual scenario would be:

- import the root CA into NSS, and mark it as trusted, for the required
  purposes (like TLS, and/or email security, e.g. -t C,C, for both)

- import both intermediates, with empty trust (e.g. using -t ,, )
  (empty trust == neutral trust)

Now, if you try to verify an end entity cert, NSS can find the all issuer certs, i 1, i 2, root CA, and see that root CA is trusted, and you're good.


Usually with TLS, on the client side, you don't need to manually import the intermediate CAs into the client database.

Instead, a server that owns and uses the end entity server certificate, should be configured to serve the server certificate and all intermediates.

Typically, SSL/TLS server software has a configuration mechanism, where you can configure the server certificate. In addition, there's usually a separate configuration setting, where you can configure the CA files, or intermediate CA files (whatever that setting is called, might vary). So, on the server side, configure that setting with a file, that contains both intermediate CAs.

Now, if a client connects to that server, the server should send a chain of server cert + intermediate 1 + intermediate 2.

If the client trusts the root CA, this will be sufficient for the client to find the chain required to trust the server.

Does this answer your question, or did I misunderstand your question?
Comment 14 Kai Engert (:kaie) (inactive account) 2016-10-05 21:29:29 UTC 
(In reply to Endi Sukma Dewata from comment #11)
> My question is, in order to validate those certificates properly do we need
> to store and trust all 3 CA certificates in the NSS database (i.e. complete
> chain is always needed)? Or if one of the CA certificates is already
> trusted, the parents of that CA certificate no longer needs to present in
> the NSS database (i.e. partial chain is sufficient)?

I think it's uncommon to mark an intermediate CA as trusted.


> Currently Dogtag allows installing a CA server with just a partial chain,

I don't understand what the motiviation for this ability might have been, and what exactly this means in your context.

Are you talking about the configuration for the https:// interface provided by that server?

Or are you talking about some internal property of the CA issueing software, that defines how your server will create new certificates for users that request it?


> but that apparently causes a problem when another system tries to interact
> with it.

Sorry, that's a bit too vague for me to draw conclusions.

What kind of problems? What kind of interaction? 


> We're wondering if it's supposed to work with partial chain or
> whether the CA server should have been installed with the complete chain in
> the first place.

If it's about the configuration for a server that accepts SSL/TLS connections, where SSL/TLS clients like Firefox connect to, then my explanation in the previous comment should clarify it.
Comment 15 Endi Sukma Dewata 2016-10-05 22:46:42 UTC 
Thanks Kai,

Dogtag is CA server that communicates through SSL/TLS connections, so it needs to be able to issue and validate certificates. Here I'm trying to make sure it handles the certificates properly as in general PKI.

In this particular case Dogtag is the "intermediate CA 2", so we need to have these certificates in the server's NSS database:

* root CA           (C,C,)
* intermediate CA 1 (empty)
* intermediate CA 2 (empty)
* server cert       (empty)

and only the root CA in the client's NSS database:

* root CA           (C,C,)

Is this correct?

Now the problem is the current Dogtag installer does not properly validate the certificate chain that was provided during installation, so it's possible that the server got installed with the following certificates:

* intermediate CA 1 (C,C,)
* intermediate CA 2 (empty)
* server cert       (empty)

Is this supposed to work?

It's not that we're trying to support this uncommon case. If this is not supposed to work we can fix the Dogtag installer to prevent this from happening in the first place. But if this is supposed to work (although uncommon) we might need to do some further investigation because there seems to be a certificate validation problem (I'll get the details if we decide to investigate it further).
Comment 16 Kai Engert (:kaie) (inactive account) 2016-10-06 12:04:46 UTC 
When you ask "is this supposed to work", you should clarify the "where".

I don't see clear yet, where exactly do you see a failure, what are you trying to fix?

Do you see a failure on the client side, when a client attempts to connect to the CA server? Please clarify what failure you get and where.

In general, the trust configured on the server side has zero effect on clients.
Comment 17 Kai Engert (:kaie) (inactive account) 2016-10-06 12:12:54 UTC 
(In reply to Endi Sukma Dewata from comment #15)
> In this particular case Dogtag is the "intermediate CA 2", so we need to
> have these certificates in the server's NSS database:
> 
> * root CA           (C,C,)
> * intermediate CA 1 (empty)
> * intermediate CA 2 (empty)
> * server cert       (empty)

looks good


> and only the root CA in the client's NSS database:
> 
> * root CA           (C,C,)

looks good


> Now the problem is the current Dogtag installer does not properly validate
> the certificate chain that was provided during installation, so it's
> possible that the server got installed with the following certificates:
> 
> * intermediate CA 1 (C,C,)
> * intermediate CA 2 (empty)
> * server cert       (empty)
> 
> Is this supposed to work?

Work for what?

I'm still guessing about which actual problem we're talking, which failure you're getting that you'd like to fix.

My guess could be totally wrong, but I'm guessing that you have a client that connects to that server, and the client cannot verify the CA server's certificate, and rejects a https:// connection to it?

If that's the failure you're worried about, then potentially your server doesn't include all intermediate CAs in the SSL/TLS handshake sent to the client, and therefore the client fails to construct a full chain.

You can inspect the chain of certificates that the server sends to you with the tstclnt tool, for example:

  tstclnt -D -b -V tls1.0:tls1.2 -C -h www.redhat.com -p 443
Comment 18 Endi Sukma Dewata 2016-10-06 19:56:48 UTC 
> Work for what?

I was asking whether the partial chain (i.e. without root CA) will allow the CA server to function normally (i.e. signing and verifying certificates) as if it has the complete chain. Apparently it does work just fine. I also verified with the tstclnt tool that the server correctly returns all certificate chain that it has (although it's only partial).

The problem originally reported in this bug was that the client (i.e. KRA) failed with an UNKNOWN_ISSUER error when contacting the CA server that only has a partial chain. I was not clear whether this error came from validation that happens on the client or the server.

Now that I have this information it's clear that the problem actually happens on the client side. I tried fixing the client to ignore UNKNOWN_ISSUER (since the client doesn't have any trust anchors) and now everything seems to be working just fine.

So thanks Kai for the information. Petr, you can ignore this since there will be no change to IPA requirement. The CA server will continue to accept partial chain like before.
Comment 19 Endi Sukma Dewata 2016-10-06 21:02:55 UTC 
Fixed in master:
* 343a756bb93abf057f2999858ba9e170fa84f143
Comment 23 Endi Sukma Dewata 2016-11-02 16:58:44 UTC 
For some reason the commit ID changed in master:
* 10b21dd71e8384d9fa0d12053278d8192eb29d00
Comment 26 Roshni 2017-05-02 14:59:40 UTC 
[root@ibm-x3650m4-02-vm-06 ~]# rpm -qi pki-ca
Name        : pki-ca
Version     : 10.4.1
Release     : 2.el7
Architecture: noarch
Install Date: Tue 02 May 2017 10:38:09 AM EDT
Group       : System Environment/Daemons
Size        : 2290616
License     : GPLv2
Signature   : RSA/SHA256, Tue 18 Apr 2017 08:37:55 PM EDT, Key ID 199e2f91fd431d51
Source RPM  : pki-core-10.4.1-2.el7.src.rpm
Build Date  : Tue 18 Apr 2017 08:09:41 PM EDT
Build Host  : ppc-041.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://pki.fedoraproject.org/
Summary     : Certificate System - Certificate Authority

KRA installation using the the CA chain described in comment 0 was successful without having to specify the chain on KRA's installation file.
Comment 27 errata-xmlrpc 2017-08-01 22:46:01 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:2110
Note You need to log in before you can comment on or make changes to this bug.