How to use new keypairs/certificates for the servers in KCA?
Originally Published: 2001-10-24
Article Number
Applies To
Issue
On installing a fresh KCA, all server certificates created during the installation expire after 3 years (if default expiration dates are chosen for the system CAs). How can those certificates be renewed? How can new keypairs be used for those server certificates?
Resolution
1. Xudad/ssl/certs/ssl.cert (corresponding key in Xudad/ssl/private/ssl.key)
2. Xudad/ssl/certs/root.cert (corresponding key in Xudad/ssl/private/root.key)
3. WebServer/ssl/certs/admin.cert (corresponding key in WebServer/ssl/private/admin.key)
4. WebServer/ssl/certs/adminServer.cert (corresponding key in WebServer/ssl/private/adminServer.key)
5. WebServer/ssl/certs/enroll.cert (corresponding key in WebServer/ssl/private/enroll.key)
6. WebServer/ssl/certs/enrollServer.cert (corresponding key in WebServer/ssl/private/enrollServer.key)
7. WebServer/ssl/certs/crl.cert (corresponding key in WebServer/ssl/private/crl.key)
8. WebServer/ssl/certs/crlServer.cert (corresponding key in WebServer/ssl/private/crlServer.key)
9. WebServer/ssl/certs/scep.cert (corresponding key in WebServer/ssl/private/scep.key)
10. WebServer/ssl/certs/scepServer.cert (corresponding key in WebServer/ssl/private/scepServer.key)
11. LogServer/ssl/certs/server_ssl.cert (corresponding key in LogServer/ssl/private/server_ssl.key)
12. LogServer/sign/certs/signing.cert (corresponding key in LogServer/sign/private/signing.key)
Note: For a detailed explanation of each one of the above certificates, please refer to the KCA Administrator's Guide v5.7, section 1.7.3 "Issued Certificates", page 48.
The keypair used in #11 is DSA, #12 is ECC, and all other keypairs are RSA.
A) How to renew the KCA server certificates:
To renew the server certificates, please follow the procedure listed on page 139, section 3.14 "Re-issuing Web Server Certificates", of the KCA Administrator's Guide 5.7.
Note that for other server certificates that are not present in the WebServer/ssl/certs/ directory need to be copied there, re-issued, and then moved back to the appropriate directory.
B) How to use new keypairs/certs for the KCA servers?
1. It is highly recommended that you make a full backup of the KCA installation. Or, at least make a backup of all the above listed certificates and keys.
2. Follow the procedure listed in the solution titled "How to generate an SSL Key and Certificate for OCSP Responder" to generate new keypairs/certificates for each one of the above listed server certs/keys. Do not generate new keys/certs for #2, #11, and #12 (please see the note below). Make sure that the certificate requests are made to and certs issued by the System CA. Save these keys and certificates in files with appropriate names as listed above.
3. Before you could start using these new server certificates, you need to update the LDAP ACL rules in KCA to allow proper permission to some of these new server certs. To do so, using a browser connect to the KCA Administration Server (https://<hostname>:<admin-port>/ca/rsakeon.xuda), click on System Configuration workbench, click on LDAP rules in the navigation area, and then add the md5 values of the new admin.cert, enroll.cert, and scep.cert in all those rules where the old certs are referenced. Do not delete any existing rules/lines. Save the updated rules by clicking on "Save ACL rules to database" button.
4. Copy all the new certificates and key files to the appropriate directories over-writing the old files (which should have been backed up in step 1.
5. Stop and start all KCA services.
Note: #2 is not used by KCA in regular operations, and it can even be removed/deleted after making a back up on a storage media and stored in a secure area. #11 and #12 contain keys based on DSA and ECC, respectively, which browsers can not generate. XDK can be used to generate a keypair/certificate based on ECC or DSA.
***** The process described above has been made very easy and intuitive in KCA 6.0. In KCA 6.0, new certificates/keypair for the servers can be changed through its administrative interface.
Related Articles
How to configure RSA Authentication Manager 8.4 or later to send data to multiple remote syslog servers Number of Views How to create a new ActiveMQ KahaDB for use with AFX in RSA Identity Governance & Lifecycle Number of Views Unable to use OCSP responder in KCA 6 on Solaris 8 Number of Views RSA Authentication Manager 8.x - Weak Ciphers Vulnerabilities found with Qualys Scan - Updated Number of Views How to use Windows Password Integration with Offline Authentication on an RSA Authentication Agent 7.x for Windows Number of Views
Trending Articles
Don't see what you're looking for?
