createAdminCertificate NullPointerException with external CA

[pki-bot]

This issue was migrated from Pagure Issue #2276. Originally filed by cheimes (@tiran) on 2016-04-11 16:19:21:

• Closed as Invalid
• Assigned to edewata (@edewata)

---

An IPA user has reported an installation failure with an external CA, https://fedorahosted.org/freeipa/ticket/5790

Dogtag installation fails with a Null pointer exception:

java.lang.NullPointerException
at com.netscape.cms.servlet.csadmin.ConfigurationUtils.createPKCS7(ConfigurationUtils.java:3536)
at com.netscape.cms.servlet.csadmin.ConfigurationUtils.createAdminCertificate(ConfigurationUtils.java:3527)
at org.dogtagpki.server.rest.SystemConfigService.configureAdministrator(SystemConfigService.java:630)
...

Could the error be related to key usage? The CA cert doesn't have Non Repudiation.

[pki-bot]

Comment from edewata (@edewata) at 2016-04-11 19:11:59

Hi,

The null pointer exception is most likely a secondary problem. I'm not sure what the primary problem is, the debug log doesn't provide enough information. It's possible that the missing key usage was causing a problem (I'm not sure either which key usages are actually required).

To my understanding the CA cert was signed with TinyCA. Based on earlier investigation, with the default settings TinyCA may generate an incompatible cert, for example the cert has subjectAltName and issuerAltName extensions with blank values. It's possible the default key usage might be incompatible as well.

Could you install the following COPR build? https://copr.fedorainfracloud.org/coprs/edewata/pki/

It should provide better debugging information to find the primary problem.

[pki-bot]

Comment from stsimb (@stsimb) at 2016-04-11 20:32:52

debug logfile with edewata pki edewata-pki.debug.gz

[pki-bot]

Comment from stsimb (@stsimb) at 2016-04-11 20:33:39

pki-ca-spawn logfile with edewata's pki repo pki-ca-spawn.20160411210229.log

[pki-bot]

Comment from stsimb (@stsimb) at 2016-04-11 20:35:49

[11/Apr/2016:21:03:51][http-bio-8443-exec-6]: Error in creating pkcs12 to backup keys and certs: java.security.cert.CertificateParsingException: java.io.IOException: IssuerAlternativeNameExtension

Attached pki-ca-spawn.20160411210229.log and edewata-pki.debug.gz using your repo.

[pki-bot]

Comment from stsimb (@stsimb) at 2016-04-11 23:01:33

Further debugging this on IRC (#dogtag-pki) turned out the following (in edewata's words):

so the problem is the root ca contains some extensions with blank values. these are issuer alt name & subject alt name. apparently those blank values are causing a problem in pki in several places.

openssl confirms this

[root@corp-ldap-03: ~]# openssl x509 -text -in root-cacert.pem

            X509v3 Issuer Alternative Name:
                <EMPTY>

certutil too

[root@corp-ldap-03: ~]# certutil -V -d /var/lib/pki/pki-tomcat/alias -n "Server-Cert cert-pki-ca" -u A
certutil: certificate is valid

[root@corp-ldap-03: ~]# certutil -V -d /var/lib/pki/pki-tomcat/alias -n "caSigningCert External CA" -u A
certutil: certificate is valid

[root@corp-ldap-03: ~]# certutil -L -d /var/lib/pki/pki-tomcat/alias -n "caSigningCert External CA"
...
            Name: Certificate Issuer Alt Name
            Error: Parsing extension: Certificate extension value is invalid.
            Data: Sequence {
            }

...

[pki-bot]

Comment from ftweedal (@frasertweedale) at 2016-04-12 03:55:05

The user should be able to reissue the root cert for the purposes of
importing it into Dogtag, without needing to distribute the
repaired root certificate to clients. The serial number is not used
in validation path construction, so as long as the same public key
and issuer/subject DN are used, clients that have the noncompliant root
certificate should be able to validate certificates issued using the
updated root certificate just fine.

(This assumes the clients themselves can handle the noncompliant certificate. If they cannot, then they'll need to redistribute a repaired root certificate no matter what.)

The original (noncompliant) root certificate should not be revoked until all clients have the new root certificate.

[pki-bot]

Comment from stsimb (@stsimb) at 2016-04-18 11:55:20

I rekey'ed my original CA without the empty issuerAltName, signed the freeipa csr with it and installation completed successfully.

So unless you want to fix this corner case in pki code, I consider this resolved.

Thank you all very much for your help.

[pki-bot]

Comment from edewata (@edewata) at 2016-04-18 20:57:35

Thanks for providing the info to improve Dogtag!

Per discussion with the team, the code conforms to RFC 5280 which does not allow empty values in the extensions, so the behavior will not be changed. However, some improvements have been made in ticket 1654 such that such problem can be investigated more easily.

[pki-bot]

Comment from mborodin (@mborodin) at 2016-05-03 23:36:10

Hello, I hit the same NullPointerException on RHEL 7 during IPA installation. My root CA certificate does not have any empty fields. After updating to edewata version I can see this in the logs:

Caused by: Failed to enable USN plugin: Property preop.internaldb.usn.ldif missing value
        at com.netscape.cms.servlet.csadmin.ConfigurationUtils.enableUSNPlugin(ConfigurationUtils.java:1297)
        at org.dogtagpki.server.rest.SystemConfigService.initializeDatabase(SystemConfigService.java:748)
        at org.dogtagpki.server.ca.rest.CAInstallerService.initializeDatabase(CAInstallerService.java:98)
        at org.dogtagpki.server.rest.SystemConfigService.configure(SystemConfigService.java:179)
        at org.dogtagpki.server.rest.SystemConfigService.configure(SystemConfigService.java:121)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        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)
        ... 53 more
Caused by: Property preop.internaldb.usn.ldif missing value
        at com.netscape.cmscore.base.PropConfigStore.getString(PropConfigStore.java:258)
        at com.netscape.cms.servlet.csadmin.ConfigurationUtils.importLDIFS(ConfigurationUtils.java:1654)
        at com.netscape.cms.servlet.csadmin.ConfigurationUtils.importLDIFS(ConfigurationUtils.java:1646)
        at com.netscape.cms.servlet.csadmin.ConfigurationUtils.enableUSNPlugin(ConfigurationUtils.java:1294)
        ... 66 more

Any help would be appreciated! Thank you.

[pki-bot]

Comment from mborodin (@mborodin) at 2016-05-03 23:39:43

Tomcat Log localhost.2016-05-03.log

[pki-bot]

Comment from edewata (@edewata) at 2016-05-11 00:18:19

Hi mborodin,

Based on the stack trace and the error message in comment 9 the NPE is happening in different part of the code. Could you please open a separate ticket and specify the platform you used, the packages you installed, and the steps to reproduce the problem. Please note that my COPR build in comment 3 was only created to troubleshoot this particular issue. Tickets should be filed based on officially released packages (including alpha/beta) or the source repository if you do a custom build.

I'm reverting this ticket to the previous closed status.

[pki-bot]

Comment from cheimes (@tiran) at 2017-02-27 14:10:53

Metadata Update from @tiran:

• Issue assigned to edewata
• Issue set to the milestone: 10.3.1