dogtagpki

#1033 IPA replica setup fails during CA setup with "unable to parse xml"
Closed: Invalid Opened by mharmsen.

Closed: Invalid
Reopen Issue

Customer wants to setup an IdM replica system with ca-subsystem. The master
server has been installed successfully with an certificate issued by an
external CA. The command to install the replica fails:

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
Configuration of CA failed

A closer look at the debug log shows the following:

RESPONSE STATUS:  HTTP/1.1 200 OK
RESPONSE HEADER:  Server: Apache-Coyote/1.1
RESPONSE HEADER:  Server: Apache-Coyote/1.1
RESPONSE HEADER:  Content-Type: application/xml;charset=UTF-8
RESPONSE HEADER:  Date: Wed, 07 May 2014 16:12:48 GMT
RESPONSE HEADER:  Connection: close
ERROR: unable to parse xml
ERROR XML =
ERROR: Tag='updateStatus' has no values
Error in DomainPanel(): updateStatus value is null
ERROR: ConfigureCA: DomainPanel() failure
ERROR: unable to create CA
#######################################################################
2014-05-07T16:12:48Z DEBUG stderr=[Fatal Error] :193:160: The entity name must
immediately follow the '&' in the entity reference.
org.xml.sax.SAXParseException; lineNumber: 193; columnNumber: 160; The entity
name must immediately follow the '&' in the entity reference.
        at org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:239)
        at
org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:283)
        at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121)
        at ParseXML.parse(ParseXML.java:169)
        at ConfigureCA.getStatus(ConfigureCA.java:205)
        at ConfigureCA.checkStatus(ConfigureCA.java:221)
        at ConfigureCA.checkStatus(ConfigureCA.java:216)
        at ConfigureCA.DomainPanel(ConfigureCA.java:332)
        at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1173)
        at ConfigureCA.main(ConfigureCA.java:1672)

The error appears after a query containing an '&' character.

It is believed that this is the reason why the installer exits with the following error:

ERROR: unable to parse xml

Test Procedure:

  • Setup a CA with a root certificate that has a '&' as part of the subject line
  • Setup an IdM master system with --external-ca option
  • Setup an IdM replica system

Additional info:

In my reproducer setup, the installation of the master IdM system already
failed when the external CA certificate has a '&' in the subject line. For
whatever reason, the setup at the customer worked and only the replica setup
failed. The attached debug log contains some additional debug data that has
been added to verify the XML data received from the ca system is clean.

The DomainPanel() function is defined in
base/silent/src/com/netscape/pkisilent/ConfigureCA.java:

public boolean DomainPanel() {
        try {
            HTTPResponse hr = null;
            String domain_url = "https://"; + cs_hostname + ":" + cs_port;
            String query_string = null;
            if (!clone) {
                query_string = "sdomainURL=" + URLEncoder.encode(domain_url,
"UTF-8")
                        + "&sdomainName=" + URLEncoder.encode(domain_name,
"UTF-8")
                        + "&choice=newdomain" + "&p=3" + "&op=next" +
"&xml=true";
            } else {
                domain_url = "https://"; + sd_hostname + ":" + sd_admin_port;
                query_string = "sdomainURL=" + URLEncoder.encode(domain_url,
"UTF-8")
                        + "&sdomainName="
                        + "&choice=existingdomain" + "&p=3" + "&op=next" +
"&xml=true";
            }
            hr = hc.sslConnect(cs_hostname, cs_port, wizard_uri, query_string);
            if (!checkStatus(hr, "updateStatus", SUCCESS, "DomainPanel()")) {
                return false;
            }
            return true;
        } catch (Exception e) {
            System.out.println("Exception in DomainPanel(): " + e.toString());
            e.printStackTrace();
            return false;
        }
    }

When addressing this issue for Bugzilla Bug #1096142 - IPA replica setup fails during CA setup with "unable to parse xml", it was discovered that this ONLY appeared to be a problem when the 'pki-silent' batch processing tool was used for configuration, and not the Firefox Browser GUI configuration.

Consequently, the 'pki-silent' tool is no longer utilized to configure CA instances. Instead, batch configuration is now handled by the 'pkispawn' installation tool via the REST interfaces.

Although this problem may not exist on Fedora platforms (e. g. - Fedora 20), this problem must still be tested to insure that it does not exist when using 'pkispawn' for configuration purposes via the REST interfaces.

This ticket was originally cloned from the RHEL 6 Bugzilla Bug #1096142 - IPA replica setup fails during CA setup with "unable to parse xml" in which it was discovered that Firefox Browser GUI-based configuration of PKI CA succeeded; only 'pki-silent' batch-based configurations failed.

In Dogtag 10, the 'pki-silent' batch-based process has been replaced by the 'pkispawn' batch-based REST interface configuration methods.

To test to see if the 'pkispawn' batch-based REST interface configuration methods were prone to this error, the following test was run:

# pkispawn -s CA -f /root/pki/bz1096142.cfg -vvv

where /root/pki/bz1096142.cfg contained the following:

[DEFAULT]
pki_admin_password=<password>
pki_backup_keys=True
pki_backup_password=<password>
pki_client_pkcs12_password=<password>
pki_ds_password=<password>
pki_security_domain_password=<password>
pki_client_database_purge=False
pki_ssl_server_subject_dn=cn=server.example.com,ou=Bread & Butter,o=Example Domain
pki_subsystem_subject_dn=cn=Subsystem Certificate,ou=Bread & Butter,o=Example Domain
[CA]
pki_ca_signing_subject_dn=cn=Certificate Authority,ou=Bread & Butter,o=Example Domain
pki_ocsp_signing_subject_dn=cn=OCSP Signing Certificate,ou=Bread & Butter,o=Example Domain
pki_admin_subject_dn=cn=CA Administrator of Instance pki-ca,uid=admin,e=admin@example.com,o=Example Domain
pki_audit_signing_subject_dn=cn=CA Audit Signing Certificate,ou=Bread & Butter,o=Example Domain

The command was executed, and a CA was successfully installed which contained the following certificates:

CN=Certificate Authority,OU=Bread & Butter,O=Example Domain
CN=OCSP Signing Certificate,OU=Bread & Butter,O=Example Domain
CN=server.example.com,OU=Bread & Butter,O=Example Domain    
CN=Subsystem Certificate,OU=Bread & Butter,O=Example Domain
CN=CA Audit Signing Certificate,OU=Bread & Butter,O=Example Domain
CN=CA Administrator of Instance pki-ca,UID=admin,E=admin@example.com,O=Example Domain

Finally, a test certificate was enrolled and approved to verify that the CA was working properly.

Therefore, this bug is being closed as invalid for Dogtag 10, since the 'pkispawn' batch-based REST interface is not prone to the same issues as its RHEL 6 'pki-silent' batch-based counterpart.

Metadata Update from @mharmsen:
- Issue assigned to mharmsen
- Issue set to the milestone: 10.2 - 06/14 (June)

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

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
Low
defect
Installation/Configuration
None
RHCust
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.