| 57434 |
On Red Hat Enterprise Linux, a new CA server will not start after configuration if a SafeNet LunaSA 3.1 hardware module is used with SHA-512 as the CA signing algorithm. The CA server returns an error that the signature on the server certificate is bad. SHA-256 can be used as the signing algorithm instead. |
| 57514 |
If a TKS master key is generated on a SafeNet LunaSA HSM, server-side key generation fails with the following error in the TKS debug log:
"can't generate key encryption key"
A similar message also appears in the debug log if server-side key generation is turned on:
"TokenServlet: key encryption key generation failed
for CUID"
where CUID is the card unique ID.
|
| 57526 |
If a server certificate contains the Authority Information Access extension, the certificate cannot be imported on an nCipher netHSM hardware token. The default caServerCert profile has this extension enabled by default. For example, when installing a subsystem such as the Token Key Service (TKS), the SSL server certificate fails to import if the certificate is processed through the default caServerCert profile because the caServerCert profile adds the Authority Information Access extension to the SSL server certificate automatically. If a CA server is already installed on the nCipher netHSM token, then the CA signing certificate is overwritten, as well. To import the server certificate properly, first remove the Authority Information Access extension from the caServerCert profile, then install the subsystem. |
| 57677 |
If the DRM response to the TPS exceeds the timeout period, the server can return the incorrect response message, 200 HTTP/1.1 OK, signaling that the operation completed successfully instead of timing out. |
| 57640 |
If a DRM version 6.1 SP4 is migrated to version 7.2, then the archived keys that were migrated cannot be recovered because the key splitting schemes are different. To be able to recover these keys, first obtain a migration patch from Red Hat services. This patch will recover the PIN needed to access the storage token where the DRM private key resides, then recover the keys and export them to a PKCS #12 file. However, this package can potentially expose security issues in the version 6.1 SP 4 DRM, so it should be used only as necessary.
For information on using these migration scripts, see the README available with the migration package. |
| 57683 |
If there are multiple enrollment operations using the tpsclient tool when server-side key generation is enabled in the TPS, then the DRM connection can time out before the TPS can generate the keys. The tool will then return the error Failed to generate key on server. Please check DRM. To correct this, edit the TPS CS.cfg configuration file and add a line increasing the timeout period for the connection to the DRM:
conn.drm1.timeout=25
|
| 57800 |
It is possible for inconsistencies to arise between the TPS database and the CA database, so that certificate statuses may not be correct. The TPS database only maintains the certificate statuses on tokens that were last seen by the TPS system. For example, if a certificate is manually revoked by the CA agent, then that revocation status does not get updated automatically in the TPS database. There is no known workaround for this issue at this time. |
| 57875 |
To verify if the full CA chain is in a security database, such as an OCSP or subordinate CA, open the security database directory, like /var/lib/instance_ID/alias.
To list all the CA certificates and their nicknames, run certutil with the following options:
certutil -d . -L
To confirm that a particular certificate is included in the database, run certutil with the following options:
certutil -d . -L -n nickname
nickname is the nickname of the certificate.
The only time a certificate chain is needed for the OCSP service is if the CA connects to the OCSP through SSL authentication when it publishes its CRL. Otherwise, the OCSP does not need to have the complete certificate chain to verify the CRL; the OCSP must have the certificate which signed the CRL, either the CA signing certificate or a CRL signing certificate. If both a root CA and one of its subordinate CAs publish CRLs to an OCSP, the OCSP needs the CA signing certificate of both CAs.
The signing certificate can be imported into the OCSP database through the OCSP agent interface. |
| 57978 |
Trying to add the nsTokenUserKeySubjectName default with No Constraint extension to a certificate profile through the Certificate Manager Console throws a null pointer exception, and the default is not added. |
| 57991 |
The server certificate nicknames created through the subsystem configuration wizard cannot be edited in the Requests and Certificates panel. These certificate nicknames are not currently shown in that part of the configuration UI; that field is left blank in the pretty-print view. This can cause naming collisions if a hardware token is used for a subsystem and server certificates are already stored on the token. |
| 58058 |
Generating key pairs on Safenet LunaSA hardware modules can fail with the error CKR_MAX_OBJECT_COUNT_EXCEEDED. On LunaSA tokens, the number of objects cannot exceed 127. When an object is deleted, the label for that object remains and is counted. Delete the empty labels to lower the count. Key generation can then proceed. |
| 58201 |
When configuring a cloned CA, the administrator certificate panel is displayed, but grayed out. Clicking Next to proceed to the next panel displays a pop-up box that the certificate was successfully imported into the browser when, actually, no action was taken. |
| 58228 |
Even after the configuration process is successfully completed, the configuration wizard page can still be accessed. This page can be disabled by removing the preop.pin parameter from the instance's CS.cfg file and restarting the instance. |
| 58301 |
Using the administrative console to renew an SSL server certificate stored on a hardware token automatically imports the server certificate into the Certificate System software token rather than the hardware token. |
| 58354 |
It is possible for a CA, DRM, OCSP, and TKS subsystem's certificates to be generated by an external root CA. For a subordinate CA in that case, the new CA signing certificate issued by the external CA must be pasted into the Requests and Certificates page; this signing certificate is then used to generate the other certificates. For DRM, OCSP, and TKS subsystems, the SSL server and client certificates and, if required, DRM transport and storage certificates are generated by the external CA. It can take several days, even weeks, to receive the certificates from the external root CA, meaning the the configuration process is suspended at the Requests and Certificates panel in the configuration wizard. When the certificates are received, they must be pasted into the Requests and Certificates panel to complete the subsystem configuration. However, reopening the configuration wizard at the beginning of the process can corrupt the previous setup. To return directly to the Requests and Certificates panel in the configuration wizard, open the configuration wizard URL with ?p=12 appended to the end. For example:
http://server.example.com:9080/ca/admin/
console/config/wizard?p=12
|
| 58464 |
On Mozilla Firefox, when accessing a subsystem URL without specifying the desired page, such as https://server.example.com:9443, it automatically redirects to https://server.example.com:9443/ca/services. The redirect does not work on Internet Explorer 6.0; when trying the URL https://server.example.com:9443, Internet Explorer opens a blank page. |
| 58518 |
When starting or stopping a CA, DRM, OCSP, or TKS on Solaris, the start and stop script can kill the process before the process completes and exits. This does not occur on a TPS subsystem on Solaris. |
| 58524 |
Before reusing an HSM to install and configure a TPS subsystem, manually delete any existing certificates from the HSM. All conflicting certificates (certificates with the same nickname) have to be removed from the HSM before the TPS is configured. Otherwise, the configuration process will still install the new certificates, but it is not certain which certificate, old or new, will be used. Running certutil with the -D option to delete the certificates does not work with the -f option to specify a password file. |
| 58555 |
Safenet LunaSA hardware modules do not have binaries for 64-bit Red Hat Enterprise Linux platforms. Trying to use LunaSA 32-bit libraries on 64-bit Red Hat Enterprise Linux platforms, including Red Hat Enterprise Linux 4 (x86_64), will fail with the following error:
ERROR: Failed to add module "lunasa". Probable cause: "/usr/lunasa/lib/libCryptoki2.so:
cannot open shared object file: No such file or directory"
|
| 58577 |
Agent authentication to an ECC-enabled CA can fail in the browser with error -12271 if an HSM has been added to the secmod.db database on the local machine. To work around this situation, delete the secmod.db database which contains the HSM entry and create a new secmod.db database. |
| 58745 |
If two TPS instances are running on the same machine, stopping or restarting one instance will automatically restart the other instance. It is recommended that only one TPS instance run per machine. |
| 58759 |
There are exception errors when trying to install a renewed certificate in the subsystem certificate database through the administrative console. Instead of using the Console to install renewed subsystem certificates, use the certutil utility. |
| 58761 |
The HTML-based instance configuration wizard is only supported on Mozilla Firefox. Using an unsupported browser can result in incorrect behavior. For example, in Microsoft Explorer, the pretty-print certificates and the certificate requests are displayed on a single line. |
| 58764 |
When setting up a clone, the Certificate System clone instance may record errors concerning the ancestorid attribute in the error log:
[30/Oct/2006:11:04:00 -0800] - warning:
ancestorid not indexed on 21
[30/Oct/2006:11:04:00 -0800] - warning:
ancestorid not indexed on 21
[30/Oct/2006:11:04:00 -0800] - warning:
ancestorid not indexed on 21
These warnings can be ignored because they only indicate that the request repository is empty at the time the clone is configured; they do not indicate a problem with the clone instance.
|
| 58773 |
If a subsystem within a security domain needs to be re-installed, there may be a subsystem user already created in the security domain CA's user database if the previous installation was either successfully completed or stopped after the security domain was selected. Since the user names are created based on the hostname and port number, if the same port number is reused, the pre-existing entry prevents the next installation from inserting its subsystem certificate into the subsystem user's entry in the security domain. This causes the instance to fail to start because the authentication to the security domain fails. This can happen on any subsystem which is reinstalled, except for the security domain CA itself.
To reinstall a subsystem without encountering these authentication errors, do the following:
When installation is aborted - or when completed, but it needs redone - remove the instance. For example:
pkiremove -pki_instance_root=/var/lib
-pki_instance_name=rhpki-tps
Open the Console for the security domain CA, and remove the subsystem user from the security domain CA user database:
pkiconsole https://server.example.com:9443/ca/
Click on Users and Groups in the left navigation tree. Click on the subsystem user name, such as TPS-server.example.com-7889. Click Delete.
Recreate the subsystem.
pkicreate -config_dir=/var/lib -subsystem_type=tps
-pki_instance_name=rhpki-tps
-secure_port=7888 -unsecure_port=7889
-user=pkiuser -group=pkigroup -verbose
Go through the configuration wizard again. The instance will restart successfully when the configuration is finished.
|
| 58779 |
When an nCipher HSM is used for a Certificate System instance, the nfast group needs to include the user ID of the Certificate System instance process. For example, since default Certificate System instances run as pkiuser, then the pkiuser group needs to be added as a member to the nfast group, if the Certificate System group has not already been added. |
| 213805 |
If a token is plugged in when the Enterprise Security Client is installed, then the client can fail to recognize the token. To be certain that the Enterprise Security Client will recognize tokens, make sure that no smart card tokens are plugged in when the Enterprise Security Client packages are installed. |