https://bugzilla.redhat.com/show_bug.cgi?id=773082 (Dogtag Certificate System)
It will be a good feature that if a user have generated certificate and private key the user can import them in Instalation Wizard. Think about migration from one certificate system to another.
Note: let's make sure issue https://fedorahosted.org/pki/ticket/855 is addressed.
[06/04/2014] - Moving to Milestone 10.3 due to schedule restrictions.
Assuming this task does not require migrating non-dogtag CA's existing cert database (a fair assumption)
I just gave this a quick thought. I think we can utilize the "external CA" feature we already have. Rough steps below needs to be tested out and maybe some other config need to be worked out manually: 1. run "external CA" step one with pkispawn 2. import non-dogtag ca keys over to the new instance -- basically abandon the csr and matching keys generated in (1) above (this part largely depends on knowing the steps on exporting keys from the non-dogtag CA, and whether the format of such can be imported into Dogtag CA with existing utilities) 3. put the existing non-dogtag ca b64 cert as well as the pkcs7 chain in the proper places pointed to by paths in the "external CA" pkispawn step two config 4. run "external CA" step two with pkispawn against the step two config in (3)
Step 2 above is the tricky part, as we don't know what other CA is capable of. Do we have a target external ca for this task? openssl? microsoft?
an update to the previous suggestion. We should implement it so that step 1 is done without server startup. It should just be step(s) to add externally signed Ca signing cert into the db. e.g. generate keys in an hsm token and produce csr; After receiving cert signed by an external ca, import the cert into token
Sever only needs to be started for installation when the cert has already been signed. This will eliminate any possible issue that could occur between "external-ca"-like two-phase thing where a server is left running while waiting for the cert to be signed. This new option can take in new parameters such as token name and ca signing cert nickname. It should skip the generation of ca signing keys and instead pulls the cert/keys already in the token to use for signing other subsystem certs.
Per CS/DS meeting of 11/02/2015: 10.3 - critical
http://pki.fedoraproject.org/wiki/Installing_with_Externaly-Signed_CA_Certificate http://pki.fedoraproject.org/wiki/Installing_with_Existing_CA_Certificate
pki-edewata-0657-1-Added-mechanism-to-import-existing-CA-certificate.patch pki-edewata-0657-1-Added-mechanism-to-import-existing-CA-certificate.patch
Added pki-server subsystem-cert-export command:
Added CLI options to simplify submitting CSR:
Added mechanism to import existing CA certificate:
Updated pki-cert and pki-server-subsystem man pages:
The changes were causing IPA installation error:
ipa : DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 416, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 406, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 918, in __create_ca_agent cert = x509.load_certificate(cert_data, x509.DER) File "/usr/lib/python2.7/site-packages/ipalib/x509.py", line 128, in load_certificate return nss.Certificate(buffer(data)) NSPRError: (SEC_ERROR_REUSED_ISSUER_AND_SERIAL) You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert.
The SEC_ERROR_REUSED_ISSUER_AND_SERIAL is actually caused by leftover certificate from previous installation. The actual problem caused by the earlier changes in this ticket is that IPA installation step 2 fails with the following error message:
CA is not installed yet. To install with an external CA is a two-stage process. First run the installer with --external-ca.
pki-edewata-0662-Fixed-external-CA-case-for-IPA-compatibility.patch pki-edewata-0662-Fixed-external-CA-case-for-IPA-compatibility.patch
Per discussions in the RHEL 7.3 Triage meeting of 01/06/2016: priority medium
Fixed external CA case for IPA compatibility:
Fixed installation summary for existing CA:
Renamed pki.nss into pki.nssdb:
Fixed KRA installation:
Checked-in to DOGTAG_10_2_6_BRANCH:
Checked-in to DOGTAG_10_2_BRANCH:
The following commit to support using a HSM with an existing CA is also related to this ticket:
6efedf46bfba0d9199bffb27e7a50afbf97e5bd5
Moving this to 10.3.1, as that is where the last commit related to this feature landed (the HSM fix mentioned in comment#30 above).
Metadata Update from @nkinder: - Issue assigned to edewata - Issue set to the milestone: 10.3.1
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/1027
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Login to comment on this ticket.