Hide Forgot
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
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.
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.
Upstream ticket: https://fedorahosted.org/pki/ticket/2497
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.
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?
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.
I don't understand the request. Could you please explain in more detail, what you're asking me to do? Thanks.
Per PKI Bug Council Meeting of 10/04/2016: 7.4
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.
The situation looks very similar to bug 1325756, comment 15
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?
(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.
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).
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.
(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
> 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.
Fixed in master: * 343a756bb93abf057f2999858ba9e170fa84f143
For some reason the commit ID changed in master: * 10b21dd71e8384d9fa0d12053278d8192eb29d00
[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.
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