dogtagpki

#503 Dogtag 10: Security Domain Issues
Closed: Fixed Opened by mharmsen.

Closed: Fixed
Reopen Issue

The following security domain issues were discovered while performing a code review on 'changes to install scripts to move calls to admin interface'.

Scenario 1:

A Master CA, a Cloned CA, and a Master KRA (in this order) were successfully installed using 'pkispawn' as BOTH the installation utility and the configuration utility.

However, when the subsystems were removed using 'pkidestroy' (Master KRA, Cloned CA, Master CA in order), while the Master KRA was removed without incident, the Cloned CA issued the following error:

# pkidestroy -s CA -i pki-tomcat-ca-clone
pkidestroy  : WARNING  ....... this 'CA' entry may not be registered with security domain 'usersys.redhat.com Security Domain'!
pkidestroy  : ERROR    ....... updateDomainXML FAILED to delete this 'CA' entry from security domain 'usersys.redhat.com Security Domain': ''

However, I was able to remove the Master CA without complaint after this.

Scenario 2:

I attempted installing a Master CA, a Cloned CA, and a Master KRA (in this order) using 'pkispawn' as the installation utility, and the browser GUI as the configuration utility.

During configuration of the KRA, on the 'Subject Names' panel, ONLY the following options were available:

URL: Certificate Authority - https://dogtag18.usersys.redhat.com:17443
     External CA

Unfortunately,this URL refers to the previously configured Cloned CA, NOT the URL to the Master CA at 8443 (https://dogtag18.usersys.redhat.com:8443), and this caused the panel to fail with the following error:

java.io.IOException: org.mozilla.jss.ssl.SSLSocketException: Unable to connect: (-5961) TCP connection reset by peer.

Upon further investigation, it was determined that during GUI configuration of the Cloned CA, the Security Domain which contained the information on the Master CA was overwritten by information on the Cloned CA:

[06/Feb/2013:02:20:35][http-bio-17443-exec-18]: getDomainXML: domainInfo=<?xml version="1.0" encoding="UTF-8" standalone="no"?><DomainInfo><Name>UsersysRedhat Domain</Name><CAList><CA><Host>dogtag18.usersys.redhat.com</Host><SecurePort>8443</SecurePort><SecureAgentPort>8443</SecureAgentPort><SecureAdminPort>8443</SecureAdminPort><SecureEEClientAuthPort>8443</SecureEEClientAuthPort><UnSecurePort>8080</UnSecurePort><Clone>FALSE</Clone><SubsystemName>Certificate Authority</SubsystemName><DomainManager>TRUE</DomainManager></CA><SubsystemCount>1</SubsystemCount></CAList><KRAList><SubsystemCount>0</SubsystemCount></KRAList><OCSPList><SubsystemCount>0</SubsystemCount></OCSPList><TKSList><SubsystemCount>0</SubsystemCount></TKSList><RAList><SubsystemCount>0</SubsystemCount></RAList><TPSList><SubsystemCount>0</SubsystemCount></TPSList></DomainInfo>
[06/Feb/2013:02:20:35][http-bio-17443-exec-18]: Cloning a domain master
[06/Feb/2013:02:20:35][http-bio-17443-exec-18]: WizardPanelBase updateDomainXML start hostname=dogtag18.usersys.redhat.com port=8443
[06/Feb/2013:02:20:35][http-bio-17443-exec-18]: WizardPanelBase updateDomainXML: status=0
[06/Feb/2013:02:20:35][http-bio-17443-exec-18]: updateSecurityDomain(): Dump contents of updated Security Domain . . .
[06/Feb/2013:02:20:35][http-bio-17443-exec-18]: getDomainXML start
[06/Feb/2013:02:20:35][http-bio-17443-exec-18]: getDomainXML: status=0
[06/Feb/2013:02:20:35][http-bio-17443-exec-18]: getDomainXML: domainInfo=<?xml version="1.0" encoding="UTF-8" standalone="no"?><DomainInfo><Name>UsersysRedhat Domain</Name><CAList><CA><Host>dogtag18.usersys.redhat.com</Host><SecurePort>17443</SecurePort><SecureAgentPort>17443</SecureAgentPort><SecureAdminPort>17443</SecureAdminPort><SecureEEClientAuthPort>17443</SecureEEClientAuthPort><UnSecurePort>17080</UnSecurePort><Clone>TRUE</Clone><SubsystemName>Certificate Authority</SubsystemName><DomainManager>TRUE</DomainManager></CA><SubsystemCount>1</SubsystemCount></CAList><KRAList><SubsystemCount>0</SubsystemCount></KRAList><OCSPList><SubsystemCount>0</SubsystemCount></OCSPList><TKSList><SubsystemCount>0</SubsystemCount></TKSList><RAList><SubsystemCount>0</SubsystemCount></RAList><TPSList><SubsystemCount>0</SubsystemCount></TPSList></DomainInfo>

The problem is not that the entries have been "replaced", but rather that the updated security domain is not reported correctly.

Changes we made recently to SecurityDomainProcessor has broken getDomainXML, specifically in the function -- convertDomainInfoToXMLObject(). Here we are iterating through hosts and adding them to the xml, but the entries in ldap are delineated by host and port. So if you have two subsystems (of the same type) on the same host with different ports in the security domain, one will not be picked up and one will not.
We should be iterating over host:port

master: c232ca016f042b46ecd60449207a8109b6c71a44

Metadata Update from @mharmsen:
- Issue assigned to edewata
- Issue set to the milestone: 10.0.2

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

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.
Metadata
None
None
None
Normal
defect
Installation/Configuration
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.