Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
DescriptionMatthew Harmsen
2016-08-31 18:39:12 UTC
The pkispawn and CS.cfg provide several parameters to specify the token name for each system certificate:
pki_ca_signing_token / ca.signing.tokenname
pki_ocsp_signing_token / ca.ocsp_signing.tokenname / ocsp.signing.tokenname
pki_storage_token / kra.storage.tokenname
pki_transport_token / kra.transport.tokenname
pki_audit_signing_token / <subsystem>.audit_signing.tokenname
pki_ssl_server_token / <subsystem>.sslserver.tokenname
pki_subsystem_token / <subsystem>.subsystem.tokenname
However, the current code disregards the token names specified in the above parameters and it will only use the token name specified in pki_token_name, which limits its use and may cause some confusions.
One option is to fix the code to read the token names from the right parameters, allowing the system certificate to be created in different tokens. For example, the CA certificate might be created in HSM, while the other certificates are created in internal token.
Another option is to remove the above parameters, so all system certificates will always be created in the same token.
Cherry-picked into DOGTAG_10_3_RHEL_BRANCH:
From f142e739d0296e29914a39c1591a5f1681f0ac31 Mon Sep 17 00:00:00 2001
From: "Endi S. Dewata" <edewata>
Date: Mon, 29 Aug 2016 08:33:05 +0200
Subject: [PATCH 3/9] Added support to create system certificates in different
tokens.
Previously all system certificates were always created in the same
token specified in the pki_token_name parameter.
To allow creating system certificates in different tokens, the
configuration.py has been modified to store the system certificate
token names specified in pki_<cert>_token parameters into the
CS.cfg before the server is started.
After the server is started, the configuration servlet will read
the token names from the CS.cfg and create the certificates in the
appropriate token.
https://fedorahosted.org/pki/ticket/2449
(cherry picked from commit bc65e12500cbc3381b4e755a4a50214f43049ad3)
(cherry picked from commit 261e550a25ced3c61fc0c3afeb910d17b7472a3c)
The patch has been reverted from DOGTAG_10_3_RHEL_BRANCH:
commit b2b617c1372559d03de582c66687df248e77fa7b
Author: Endi S. Dewata <edewata>
Date: Thu Sep 8 20:06:19 2016 +0200
Removed support for creating system certificates in different tokens.
The patch that added the support for creating system certificates
in different tokens causes issues in certain cases, so for now it
has been reverted.
https://fedorahosted.org/pki/ticket/2449
(cherry picked from commit b0a4981937abb1a3decad7decc0a788473464039)
(cherry picked from commit 744c506e41f33c7532c0ce8ab08f12bc75d79506)
The pkispawn and CS.cfg provide several parameters to specify the token name for each system certificate: pki_ca_signing_token / ca.signing.tokenname pki_ocsp_signing_token / ca.ocsp_signing.tokenname / ocsp.signing.tokenname pki_storage_token / kra.storage.tokenname pki_transport_token / kra.transport.tokenname pki_audit_signing_token / <subsystem>.audit_signing.tokenname pki_ssl_server_token / <subsystem>.sslserver.tokenname pki_subsystem_token / <subsystem>.subsystem.tokenname However, the current code disregards the token names specified in the above parameters and it will only use the token name specified in pki_token_name, which limits its use and may cause some confusions. One option is to fix the code to read the token names from the right parameters, allowing the system certificate to be created in different tokens. For example, the CA certificate might be created in HSM, while the other certificates are created in internal token. Another option is to remove the above parameters, so all system certificates will always be created in the same token.