I tried to install a kra instance (with independent tomcat) to a subordinate ca and failed. i ran into configureCACertChain() where ConfigurationUtils.getPortFromSecurityDomain() is hardcoded with "CA" as csType.. it failed because in getPortFromSecurityDomain() the port resolved to 0... I added more debugging in base/server/cms/src/org/dogtagpki/server/rest/SystemConfigService.java and found out that getPortFromSecurityDomain() resolved to 0 for the admin_port
Here is the pkispawn config I used
[DEFAULT] pki_admin_password=<my password> pki_client_pkcs12_password=<my password> pki_client_database_password=<my password> pki_ds_password=<my password> pki_security_domain_password=<my password> pki_ajp_port=28209 pki_http_port=28280 pki_https_port=28643 pki_instance_name=pki-kra2 pki_issuing_ca=https://<my host>:28543 pki_security_domain_hostname=<my host> pki_security_domain_https_port=8443 pki_security_domain_user=caadmin pki_tomcat_server_port=28205 [KRA] pki_import_admin_cert=False pki_profiles_in_ldap=False pki_san_inject=True pki_san_for_server_cert=<my host>
cfu had discussions with one of our customers, and it was determined that this would be an issue in the very near future. Consequently, marking this as a "critical" bug for 10.2.4.
I was not able to reproduce the problem with the following deployment configurations.
Root CA on pki-tomcat instance:
[CA] pki_admin_email=caadmin@example.com pki_admin_name=caadmin pki_admin_nickname=caadmin pki_admin_password=Secret123 pki_admin_uid=caadmin pki_backup_keys=True pki_backup_password=Secret123 pki_client_database_password=Secret123 pki_client_database_purge=False pki_client_pkcs12_password=Secret123 pki_ds_base_dn=dc=ca,dc=example,dc=com pki_ds_database=ca pki_ds_password=Secret123 pki_security_domain_name=EXAMPLE pki_token_password=Secret123
Sub CA on pki-subca instance:
[DEFAULT] pki_instance_name=pki-subca pki_http_port=18080 pki_https_port=18443 pki_ajp_port=18010 pki_tomcat_server_port=18006 [CA] pki_admin_password=Secret123 pki_admin_email=caadmin@example.com pki_admin_name=caadmin pki_admin_nickname=caadmin pki_admin_uid=caadmin pki_subordinate=True pki_issuing_ca=https://server.example.com:8443 pki_ca_signing_subject_dn=cn=CA Subordinate Signing,dc=example,dc=com pki_backup_keys=True pki_backup_password=Secret123 pki_client_database_password=Secret123 pki_client_database_purge=False pki_client_pkcs12_password=Secret123 pki_ds_base_dn=dc=ca,dc=sub,dc=example,dc=com pki_ds_database=subca pki_ds_password=Secret123 pki_security_domain_name=EXAMPLE pki_security_domain_password=Secret123 pki_security_domain_hostname=server.example.com pki_security_domain_https_port=8443 pki_security_domain_user=caadmin pki_token_password=Secret123
KRA for the sub CA on pki-subkra instance:
[DEFAULT] pki_instance_name=pki-subkra pki_http_port=28080 pki_https_port=28443 pki_ajp_port=28010 pki_tomcat_server_port=28006 [KRA] pki_import_admin_cert=False pki_admin_email=kraadmin@example.com pki_admin_name=kraadmin pki_admin_nickname=kraadmin pki_admin_password=Secret123 pki_admin_uid=kraadmin pki_backup_password=Secret123 pki_client_database_password=Secret123 pki_client_database_purge=False pki_client_pkcs12_password=Secret123 pki_clone_pkcs12_password=Secret123 pki_ds_base_dn=dc=kra,dc=sub,dc=example,dc=com pki_ds_database=subkra pki_ds_password=Secret123 pki_ds_hostname=server.example.com pki_security_domain_name=EXAMPLE pki_security_domain_user=caadmin pki_security_domain_password=Secret123 pki_security_domain_hostname=server.example.com pki_security_domain_https_port=8443 pki_issuing_ca=https://server.example.com:18443 pki_token_password=Secret123
The installation completed successfully. Certificate enrollment with key archival against the sub CA works fine and the key gets archived in KRA.
I'd suggest lowering the priority or closing the ticket.
I agree we can lower this to 10.2.5 so I can try it again. In my scenario, I also created another kra instance for the root CA so there were actually two kra's in the SD. I will try again later. Thank you Endi for looking into this.
Due to testing provided by edewata and cfu, on 05/21/2015, I received acknowledgement that this ticket could be moved to the 10.2.5 milestone.
Cleaned log messages:
I reproduced it again with the new rpms and all. The following is im the 2nd kra's debug log. Again, I did install a kra for the root CA, which may or may not be the cause of the issue, but that seems to be the only thing I did differently from Endi.
[26/May/2015:20:07:13]http-bio-28643-exec-3: local CA selected [26/May/2015:20:07:13]http-bio-28643-exec-3: ConfigurationUtils: Searching for SecureAdminPort in CA hosts [26/May/2015:20:07:13]http-bio-28643-exec-3: ConfigurationUtils: host: vm-058.idm.lab.bos.redhat.com [26/May/2015:20:07:13]http-bio-28643-exec-3: ConfigurationUtils: SecurePort port: 8443 [26/May/2015:20:07:13]http-bio-28643-exec-3: ConfigurationUtils: SecureAdminPort port not found [26/May/2015:20:07:13]http-bio-28643-exec-3: getHttpResponse: org.mozilla.jss.ssl.SSLSocketException: Unable to connect: (-5961) TCP connection reset by peer. com.netscape.certsrv.base.PKIException: Error in obtaining certificate chain from issuing CA: java.io.IOException: org.mozilla.jss.ssl.SSLSocketException: Unable to connect: (-5961) TCP connection reset by peer. at org.dogtagpki.server.rest.SystemConfigService.configureCACertChain(SystemConfigService.java:787) at org.dogtagpki.server.rest.SystemConfigService.configure(SystemConfigService.java:170) at org.dogtagpki.server.rest.SystemConfigService.configure(SystemConfigService.java:117
Thought I'd give it one more shot. I pkidestroy'd everything and reinstalled, this time without a kra for the root ca. The result is exactly the same. Looking closely, my subca's config is missing the following: pki_subordinate=True
By adding that to the subordinate ca, the kra for the subCA installed successfully.
So I guessed wrong, the parameter pki_issuing_ca alone does not indicate that this ca is a subordinate ca. It just seems like it could though.
I'm closely this ticket as not a bug.
Metadata Update from @cfu: - Issue set to the milestone: 10.2.5
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/1934
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Login to comment on this ticket.