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.

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

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

```2016-04-11 21:03:51 pkispawn : ERROR ....... ParseError: not well-formed (invalid token): line 1, column 0: {"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base.PKIException","Code":500,"Message":"Error in creating pkcs12 to backup keys and certs: java.security.cert.CertificateParsingException: java.io.IOException: IssuerAlternativeNameExtension"}

[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.

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 {
            }

...

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.

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.

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.

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.

Tomcat Log
localhost.2016-05-03.log

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.

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

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.