Overview#
This document describes what is required and what happens during various installation and migration cases. This document assumes that the migration happens before the CA certificate expires, so it’s highly desired to keep the original CSR during migration. To renew expiring CA certificate the admin may either reuse the same CSR, or generate a new CSR to meet the latest security requirements.
To preserve the CSR safely, the CSR will be stored in the request record in the DS instead of CS.cfg. That way during migration the CSR will be migrated automatically along with other entries in DS.
If the request record contains a profile, that means the certificate can be renewed internally by Dogtag. If it doesn’t have a profile, the certificate can only be renewed externally, then imported into Dogtag.
Installation cases:
Installation with “internally-generated self-signed” CA certificate is the “basic” CA installation where the CA certificate is generated and signed by the CA itself.
Installation with “externally-generated self-signed” CA certificate is the “existing” CA installation where the CA certificate is generated and signed by third-party CA (e.g. OpenSSL).
Installation with “externally-signed” CA certificate is the “external” CA installation where the CSR is generated by this installation process but signed by third-party CA (e.g. Verisign).
Migration cases:
Migration with “internally-generated self-signed” CA certificate is the “existing” CA installation where the CA was initially installed with “internally-generated self-signed” CA certificate.
Migration with “externally-generated self-signed” CA certificate is the “existing” CA installation where the CA was initially installed with “externally-generated self-signed” CA certificate.
Migration with “externally-signed” CA certificate is the “existing” CA installation where the CA was initially installed with “externally-signed” CA certificate.
Initial Installation#
CA subsystem#
Certificate |
Requires CSR |
Store CSR in CS.cfg |
Create Certificate Record |
Create Request Record |
|---|---|---|---|---|
Internall y-generated self-signed CA certificate |
No (will be generated) |
[STR IKEOUT:Yes] No |
Yes |
Yes (with profile) |
Externall y-generated self-signed CA certificate |
[STR IKEOUT:Yes] Optional |
[STR IKEOUT:Yes] No |
Yes |
[ST RIKEOUT:No] Only if CSR provided (without profile) |
Extern ally-signed CA certificate |
No (will be generated) |
[STR IKEOUT:Yes] No |
No |
[ST RIKEOUT:No] Yes (without profile) |
Non-CA subsystem#
Certificate |
Requires CSR |
Store CSR in CS.cfg |
Create Certificate Record |
Create Request Record |
|---|---|---|---|---|
PKI CA-signed system certificate |
No (will be generated) |
Yes |
Yes (in CA) |
Yes (in CA) |
3rd-p arty-signed system certificate |
No (will be generated) |
Yes |
No |
No |
Migration#
CA subsystem#
Certificate |
Requires CSR |
Store CSR in CS.cfg |
Create Certificate Record |
Create Request Record |
|---|---|---|---|---|
Internall y-generated self-signed CA certificate |
[STR IKEOUT:Yes] No |
[STR IKEOUT:Yes] No |
[STR IKEOUT:Yes] No (will be imported) |
No (will be imported with profile) |
Externall y-generated self-signed CA certificate |
[STR IKEOUT:Yes] No |
[STR IKEOUT:Yes] No |
[STR IKEOUT:Yes] No (will be imported) |
No (will be imported without profile) |
Extern ally-signed CA certificate |
[STR IKEOUT:Yes] No |
[STR IKEOUT:Yes] No |
No |
No (will be imported without profile) |
Non-CA subsystem#
Migration is not supported.
CLI#
To restore the certificate data and CSR in CS.cfg after install/migration:
$ pki-server subsystem-cert-update <subsystem ID> <certificate ID>