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 1445519 - CA Server installation with HSM fails
Summary: CA Server installation with HSM fails
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pki-core
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: rc
: ---
Assignee: Jack Magne
QA Contact: Asha Akkiangady
URL:
Whiteboard:
Depends On: 1447436
Blocks: 1393633
TreeView+ depends on / blocked
 
Reported: 2017-04-25 21:05 UTC by Asha Akkiangady
Modified: 2020-10-04 21:27 UTC (History)
5 users (show)

Fixed In Version: pki-core-10.4.1-7.el7
Doc Type: No Doc Update
Doc Text:
This whole issue only appeared during development when some selinux issues sprouted. The user will never know that there was an issue by the time of shipment.
Clone Of:
Environment:
Last Closed: 2017-08-01 22:50:57 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github dogtagpki pki issues 2780 0 None closed CA Server installation with HSM fails 2021-02-07 07:16:35 UTC
Red Hat Product Errata RHBA-2017:2110 0 normal SHIPPED_LIVE pki-core bug fix and enhancement update 2017-08-01 19:36:59 UTC

Description Asha Akkiangady 2017-04-25 21:05:12 UTC 
Description of problem:
CA installation with both Thales and lunaSA HSM fails.

Version-Release number of selected component (if applicable):
pki-ca-10.4.1-2.el7.noarch


How reproducible:
Always

Steps to Reproduce:
0. Set-up the system as a HSM client.

1. Create a LDAP server instance CC-NonTMS-LDAP running at port 389.

2. CA configuration for installation with lunaSA is as follows:
 
# cat ca_hsm.inf
[DEFAULT]
pki_instance_name=rhcs92-CA-aakkiang
pki_https_port=28443
pki_http_port=28080

pki_hsm_enable=True
pki_hsm_libfile=/usr/safenet/lunaclient/lib/libCryptoki2_64.so
pki_hsm_modulename=<lunasa_module_name>
pki_token_name=<lunasa_module_name>
pki_token_password=<lunasa_password>

pki_ssl_server_token=<lunasa_module_name>
pki_subsystem_token=<lunasa_module_name>
pki_audit_signing_token=<lunasa_module_name>

[Tomcat]
pki_ajp_port=28009
pki_tomcat_server_port=28005

[CA]
pki_ca_signing_token=<lunasa_module_name>
pki_ocsp_signing_token=<lunasa_module_name>

pki_admin_email=caadmin
pki_admin_name=caadmin
pki_admin_nickname=caadmin
pki_admin_password=Secret.123
pki_admin_uid=caadmin

pki_client_database_password=Secret.123
pki_client_database_purge=False
pki_client_pkcs12_password=Secret.123

pki_ds_password=SECret.123
pki_ds_secure_connection=False
pki_ds_remove_data=True

pki_ds_base_dn=dc=ca,dc=pki,dc=example,dc=com
pki_ds_database=CC-NonTMS-LDAP

pki_security_domain_name=EXAMPLE
pki_security_domain_https_port=28443

3. # pkispawn -s CA -f ca_hsm.inf -vvv

Actual results:
Installation failed:
com.netscape.certsrv.base.BadRequestException: Invalid Token provided. No such token.

Debug log has this:
[25/Apr/2017:16:20:45][http-bio-28443-exec-4]: === Token Authentication ===
[25/Apr/2017:16:20:45][http-bio-28443-exec-4]: Invalid Token provided. No such token.
[25/Apr/2017:16:20:45][http-bio-28443-exec-4]: SignedAuditEventFactory: create() message created for eventType=ACCESS_SESSION_TERMINATED


Expected results:
Installation should be successful using both Thales and LunaSA HSMs.

Additional info:
Comment 3 Matthew Harmsen 2017-04-25 23:07:49 UTC 
Upstream ticket:
https://pagure.io/dogtagpki/issue/2660
Comment 7 Jack Magne 2017-05-02 01:47:51 UTC 
After some arduous debugging, I finally at least figured out, (with a quick assist from Matt), what is going on.

It turns out that ONLY when running out our server, JSS can not get a full list of all the modules registered into the NSS db
associated with the CA.

What was most vexing is that the "TokenInfo" java tool, we ship with the server, shows the nfast token just fine in it's list.
This tool makes uses of the same code that is used when the CA starts up and calls JSS to get a list of modules and tokens.

Upon suggestion of Matt I took the box in question and put SELinux into permissive mode. Magically our tomcat server could get
a correct list of modules. The theory is that the server is not being allowed to contact / load the library for the nfast module,
associated with the hsm.

I suspect we have an issue with the selinux policy, but specific to our server running under tomcat. The reason for this is because one of
our Java tools running standalone without tomcat suffer no such issue.


Here is an example of a denial I got when trying to start an already installed server by putting selinux back into enforcing mode.

time->Tue May  2 03:34:36 2017
type=SYSCALL msg=audit(1493688876.988:458325): arch=c000003e syscall=2 success=no exit=-13 a0=7f69cc73a660 a1=80000 a2=7f69cc6ea250 a3=6b6362696c2f3131 items=0 ppid=1 pid=19365 auid=4294967295 uid=17 gid=17 euid=17 suid=17 fsuid=17 egid=17 sgid=17 fsgid=17 tty=(none) ses=4294967295 comm="java" exe="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-9.b14.el7.x86_64/jre/bin/java" subj=system_u:system_r:tomcat_t:s0 key=(null)
type=AVC msg=audit(1493688876.988:458325): avc:  denied  { search } for  pid=19365 comm="java" name="nfast" dev="dm-0" ino=566293 scontext=system_u:system_r:tomcat_t:s0 tcontext=unconfined_u:object_r:pki_common_t:s0 tclass=dir
Comment 10 Asha Akkiangady 2017-05-30 12:56:26 UTC 
RHCS subsystems installation with nCipher and LunaSA HSMs are successful with following selinux policy build:

selinux-policy-3.13.1-152.el7.noarch
selinux-policy-targeted-3.13.1-152.el7.noarch
Comment 11 Matthew Harmsen 2017-05-30 15:25:43 UTC 
commit 5e5eb07b90340eb0e46ab4a1ac76a5f77646f134
Author: Matthew Harmsen <mharmsen>
Date:   Tue May 30 09:23:55 2017 -0600

    Updated minimum selinux-policy-targeted runtime requirement.
    
    - Bugzilla Bug #1445519 - CA Server installation with HSM fails
Comment 13 Asha Akkiangady 2017-06-16 16:47:15 UTC 
Tested in version: 
pki-server-10.4.1-9.el7.noarch
selinux-policy-3.13.1-162.el7.noarch
selinux-policy-targeted-3.13.1-162.el7.noarch

RHCS subsystems CA, KRA, OCSP, TKS and TPS install with both Thales and LunaSA HSM is successful.


Marking the bug verified.
Comment 14 errata-xmlrpc 2017-08-01 22:50:57 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://access.redhat.com/errata/RHBA-2017:2110
Note You need to log in before you can comment on or make changes to this bug.