RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pki-core
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 7.3
Assignee: RHCS Maintainers
QA Contact: Asha Akkiangady
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-22 13:38 UTC by Roshni
Modified: 2020-10-04 21:13 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:
Environment:
Last Closed: 2016-11-04 05:26:29 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github dogtagpki pki issues 2543 0 None None None 2020-10-04 21:13:16 UTC
Red Hat Product Errata RHBA-2016:2396 0 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):
pki-ca-10.3.3-3.1.el7.noarch

How reproducible:
always

Steps to Reproduce:
[root@nocp4 ~]# cat ca-existing.cfg 
[DEFAULT]
pki_instance_name=pki-ca-roshni-July22
pki_admin_password=Secret123
pki_client_pkcs12_password=Secret123
pki_ds_password=Secret123
pki_ds_ldap_port=389
pki_hsm_enable=True
pki_hsm_libfile=/opt/nfast/toolkits/pkcs11/libcknfast.so
pki_hsm_modulename=nfast
pki_token_name=NHSM6000
pki_token_password=redhat123

[CA]
pki_existing=True
pki_ca_signing_csr_path=ca_signing.csr
pki_ca_signing_cert_path=ca_signing.crt

[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 nocp4.idm.lab.eng.rdu2.redhat.com 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 nocp4.idm.lab.eng.rdu2.redhat.com 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 
OK:

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:

pki_serial_number_range_start=10000
pki_request_number_range_start=11000


Config for the cert file method


[DEFAULT]
pki_instance_name=pki-ca-roshni-July22
pki_admin_password=xxxx
pki_client_pkcs12_password=xxxx
pki_ds_password=xxxx
pki_ds_ldap_port=389
pki_hsm_enable=True
pki_hsm_libfile=/opt/nfast/toolkits/pkcs11/libcknfast.so
pki_hsm_modulename=nfast
pki_token_name=NHSM6000
pki_token_password=xxxx

[CA]
pki_existing=True
pki_ca_signing_token=NHSM6000
pki_ca_signing_csr_path=ca_signing.csr
pki_ca_signing_cert_path=ca_signing.crt
pki_ocsp_signing_nickname=pki-ca-July23-roshni-ocspSigning-cert
pki_audit_signing_nickname=pki-ca-July23-roshni-auditSigning-cert
pki_ssl_server_nickname=pki-ca-July23-roshni-server-cert
pki_subsystem_nickname=pki-ca-July23-roshni-subsystem-cert

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

pki_serial_number_range_start=10000
pki_request_number_range_start=11000


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 
Jack,

the above comments are not related to this bug. I am copying the above comments to https://bugzilla.redhat.com/show_bug.cgi?id=1358876
Comment 4 Matthew Harmsen 2016-08-03 01:25:12 UTC 
Upstream ticket:
https://fedorahosted.org/pki/ticket/2423
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 <edewata>
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.
    
    https://fedorahosted.org/pki/ticket/2423
    (cherry picked from commit 389420ad4ea9994fb54132454a14abbb83c2c35d)
    (cherry picked from commit f4f62162f16da41a74328889bf2e0d17c223d48d)

commit d5d19fc9b4d4d92c02fe2e75626f69c124ecd040
Author: Endi S. Dewata <edewata>
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.
    
    https://fedorahosted.org/pki/ticket/2423
    (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  : ppc-042.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://pki.fedoraproject.org/
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 
[DEFAULT]
pki_instance_name=pki-ca-rpattath-Sep21-2016-nocp4
pki_admin_password=Secret123
pki_client_pkcs12_password=Secret123
pki_ds_password=Secret123
pki_ds_ldap_port=389
pki_hsm_enable=True
pki_hsm_libfile=/opt/nfast/toolkits/pkcs11/libcknfast.so
pki_hsm_modulename=nfast
pki_token_name=NHSM6000-OCS
pki_token_password=redhat123

[CA]
pki_existing=True
pki_ca_signing_csr_path=ca_signing.csr
pki_ca_signing_cert_path=ca_signing.crt
pki_ca_signing_nickname=caSigningCert cert-pki-ca-rpattath-Sep20-2016-nocp1
pki_ds_base_dn=dc=nocp1.idm.lab.eng.rdu2.redhat.com-pki-ca-rpattath-Sep20-2016-nocp1
pki_ds_database=nocp1.idm.lab.eng.rdu2.redhat.com-pki-ca-rpattath-Sep20-2016-nocp1
pki_serial_number_range_start=20
pki_request_number_range_start=30
pki_master_crl_enable=False
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.

https://rhn.redhat.com/errata/RHBA-2016-2396.html
Note You need to log in before you can comment on or make changes to this bug.