Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1359196 - pki_ca_signing_token when not specified does not fallback to pki_token_name value
Summary: pki_ca_signing_token when not specified does not fallback to pki_token_name v...
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pki-core
Version: 7.3
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: 7.3
Assignee: RHCS Maintainers
QA Contact: Asha Akkiangady
Depends On:
TreeView+ depends on / blocked
Reported: 2016-07-22 13:38 UTC by Roshni
Modified: 2016-11-04 05:26 UTC (History)
5 users (show)

Fixed In Version: pki-core-10.3.3-8.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2016-11-04 05:26:29 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2396 normal SHIPPED_LIVE pki-core bug fix and enhancement update 2016-11-03 13:55:03 UTC

Description Roshni 2016-07-22 13:38:41 UTC
Description of problem:
pki_ca_signing_token when not specified does not fallback to pki_token_name value

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
[root@nocp4 ~]# cat ca-existing.cfg 


[root@nocp4 ~]# pkispawn -s CA -f ca-existing.cfg 
Log file: /var/log/pki/pki-ca-spawn.20160721163125.log
Loading deployment configuration from ca-existing.cfg.
Installing CA into /var/lib/pki/pki-ca-roshni-July22.
Storing deployment configuration into /etc/sysconfig/pki/tomcat/pki-ca-roshni-July22/ca/deployment.cfg.
Module "nfast" added to database.
pkispawn    : ERROR    ....... Exception from Java Configuration Servlet: 500 Server Error: Internal Server Error
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 populating database: java.lang.NullPointerException"} 

Installation failed: not well-formed (invalid token): line 1, column 0

Actual results:
Searching for the cert in internaldb and fails

Expected results:
Should search in NHSM6000

Additional info:
log message
[21/Jul/2016:16:34:05][http-bio-8443-exec-3]: increasing minimum connections by 3
[21/Jul/2016:16:34:05][http-bio-8443-exec-3]: new total available connections 3
[21/Jul/2016:16:34:05][http-bio-8443-exec-3]: new number of connections 3
[21/Jul/2016:16:34:05][http-bio-8443-exec-3]: registered: false
[21/Jul/2016:16:34:05][http-bio-8443-exec-3]: CertificateAuthority init
[21/Jul/2016:16:34:05][http-bio-8443-exec-3]: Creating LdapBoundConnFactor(CertificateAuthority)
[21/Jul/2016:16:34:05][http-bio-8443-exec-3]: LdapBoundConnFactory: init
[21/Jul/2016:16:34:05][http-bio-8443-exec-3]: LdapBoundConnFactory:doCloning true
[21/Jul/2016:16:34:05][http-bio-8443-exec-3]: LdapAuthInfo: init()
[21/Jul/2016:16:34:05][http-bio-8443-exec-3]: LdapAuthInfo: init begins
[21/Jul/2016:16:34:05][http-bio-8443-exec-3]: LdapAuthInfo: init: prompt is internaldb
[21/Jul/2016:16:34:05][http-bio-8443-exec-3]: LdapAuthInfo: init: try getting from memory cache
[21/Jul/2016:16:34:05][http-bio-8443-exec-3]: LdapAuthInfo: init: got password from memory
[21/Jul/2016:16:34:05][http-bio-8443-exec-3]: LdapAuthInfo: init: password found for prompt.
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: LdapAuthInfo: password ok: store in memory cache
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: LdapAuthInfo: init ends
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: init: before makeConnection errorIfDown is false
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: makeConnection: errorIfDown false
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: Established LDAP connection using basic authentication to host port 389 as cn=Directory Manager
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: initializing with mininum 3 and maximum 15 connections to host port 389, secure connection, false, authentication type 1
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: increasing minimum connections by 3
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: new total available connections 3
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: new number of connections 3
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: Cert Repot inited
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: CRL Repot inited
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: Replica Repot inited
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: CertificateAuthority:initSigUnit: ca cert found
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: CertificateAuthority: initSigUnit 1- setting mIssuerObj and mSubjectObj
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: ca.signing Signing Unit nickname caSigningCert cert-pki-ca-roshni-July22 CA
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: Got token Internal Key Storage Token by name
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: Found cert by nickname: 'caSigningCert cert-pki-ca-roshni-July22 CA' with serial number: 1
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: converted to x509CertImpl
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: SigningUnit: Certificate object not found
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: CA signing key and cert not (yet) present in NSSDB
[21/Jul/2016:16:34:06][http-bio-8443-exec-3]: Error in populating database: java.lang.NullPointerException

Comment 2 Jack Magne 2016-07-23 00:40:14 UTC

I got on roshni's machine to investigate.

I felt it most expedient to get the "cert file" method working:

The first couple of attempt failed even though we specified nicknames for the non ca signing subsystem certs. Doing so causes the installer to create and install those particular certs with the given nicknames.

It turned out that giving those certs new nicknames was not sufficient to avoid conflicts with other certs already installed by the original CA instance on the HSM.

For instance this cert from the original CA:

NHSM6000:ocspSigningCert cert-pki-ca-roshni-July22 CA

Has a given serial number and issuer.
The serial number will be a standard issue number for this particular subsystem cert for a stock new install of a CA. The issuer will of course be the existing CA's issuer.

When we come back and try to install the NEW CA on another machine (using the same hsm) and same ca signing cert as desired. (using the provided ca signing cert file), a problem arises.

The acknowledgment of the existing CA signing cert appears to work just fine and all is happy there.

Issues happen when the CA tries to create locally and install the other subsystem certs. The first problem cert is the ocsp signing cert which we have given a new nickname.

What happens is the token tries to install this cert but realized that the HSM already has a cert with the same nickname and issuer number , which is flagged as illegal by NSS. The cert in question is the ocspSigningCert we talked about above. The reason why the serial number is the same is because we are doing a stock install and the ocsp signing cert is likely to assign the same number as the previous CA. The issuer is the same due to obvious reasons because we are trying to use the existing CA cert in some sort of migration procedure.

The fix here is to provide in the new CA's pkispawn cfg file a couple of params that deal with the starting serial number and starting request number.
We need to make the values exceed the end value of what the old CA issued. If there is a range specified originally or if random serial numbers are requested in a range. This starting serial number must be greater than the end of any given range.

Provided below is a sample pkispawn cfg file that I used to get a new instance installing and running correctly:

The key values needed are as this ex:


Config for the cert file method



#Note we NEED these values to get the scenario to work properly
# Choose the actual numbers as needed, for this test I just made them
# arbitrarily big to make sure there are no problems.


Roshni, I left up the vnc session we had with the instance running and set up for you to look at if needed.

Comment 3 Roshni 2016-07-25 15:44:48 UTC

the above comments are not related to this bug. I am copying the above comments to

Comment 4 Matthew Harmsen 2016-08-03 01:25:12 UTC
Upstream ticket:

Comment 5 Matthew Harmsen 2016-08-29 22:27:09 UTC
Cherry-picked in to DOGTAG_10_3_RHEL_BRANCH:

commit 40509684cb71d3863d150a2844e02a7b9321f5d8
Author: Endi S. Dewata <>
Date:   Sun Aug 28 20:38:48 2016 +0200

    Fixed default token name for system certificates.
    Previously when installing with HSM the token name has to be
    specified for each system certificate in the pki_<cert>_token
    parameters. The deployment tool has been modified such that by
    default it will use the token name specified in pki_token_name.
    (cherry picked from commit 389420ad4ea9994fb54132454a14abbb83c2c35d)
    (cherry picked from commit f4f62162f16da41a74328889bf2e0d17c223d48d)

commit d5d19fc9b4d4d92c02fe2e75626f69c124ecd040
Author: Endi S. Dewata <>
Date:   Sat Aug 27 00:07:08 2016 +0200

    Moved subsystem initialization after database initialization.
    Previously issues with system certificates that happen during
    subsystem initialization were reported as database initialization
    error. Database initialization actually does not depend on
    subsystem initialization, so to avoid confusion and to simplify the
    code the reInitSubsystem() in SystemConfigService is now invoked
    after the initializeDatabase() is complete.
    (cherry picked from commit 9f954fda5fdeda229662a466e645561639ac8402)
    (cherry picked from commit 465bf002c0671e7251738ce9a4e54bba9853780a)

Comment 7 Roshni 2016-09-20 20:54:50 UTC
[root@nocp4 ~]# rpm -qi pki-ca
Name        : pki-ca
Version     : 10.3.3
Release     : 10.el7
Architecture: noarch
Install Date: Fri 16 Sep 2016 10:16:26 AM EDT
Group       : System Environment/Daemons
Size        : 2431460
License     : GPLv2
Signature   : RSA/SHA256, Wed 14 Sep 2016 10:06:35 AM EDT, Key ID 938a80caf21541eb
Source RPM  : pki-core-10.3.3-10.el7.src.rpm
Build Date  : Sat 10 Sep 2016 02:18:45 AM EDT
Build Host  :
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <>
Vendor      : Red Hat, Inc.
URL         :
Summary     : Certificate System - Certificate Authority

Tested CA migration from CS 8.x to CS 9.1. pkispawn using the following config was successful

[root@nocp4 ~]# cat ca.cfg 

pki_ca_signing_nickname=caSigningCert cert-pki-ca-rpattath-Sep20-2016-nocp1

Comment 9 errata-xmlrpc 2016-11-04 05:26:29 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

Note You need to log in before you can comment on or make changes to this bug.