Bug 1289323
Summary: | [RFE] Provide the user the ability to import their own CA certificate with private key | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Endi Sukma Dewata <edewata> | ||||||||||
Component: | pki-core | Assignee: | Endi Sukma Dewata <edewata> | ||||||||||
Status: | CLOSED ERRATA | QA Contact: | Asha Akkiangady <aakkiang> | ||||||||||
Severity: | high | Docs Contact: | Marc Muehlfeld <mmuehlfe> | ||||||||||
Priority: | high | ||||||||||||
Version: | 7.3 | CC: | alee, arubin, bbonok, cfu, dpal, edewata, enewland, gkapoor, jkurik, mharmsen, mkosek, mniranja, nkinder, pbokoc | ||||||||||
Target Milestone: | rc | Keywords: | FutureFeature, ZStream | ||||||||||
Target Release: | 7.3 | ||||||||||||
Hardware: | Unspecified | ||||||||||||
OS: | Unspecified | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | pki-core-10.3.1-1.el7 | Doc Type: | Enhancement | ||||||||||
Doc Text: |
Deploying the Certificate System using an existing CA certificate and key
Previously, the Certificate System generated the key for the certificate authority (CA) certificate internally. With this update, the key generation is optional and the Certificate System now supports reusing an existing CA certificate and key which can be provided by using a PKCS#12 file or a hardware security module (HSM). This mechanism enables the administrator to migrate from an existing CA to the Certificate System.
|
Story Points: | --- | ||||||||||
Clone Of: | 773082 | ||||||||||||
: | 1308852 1310195 1373526 (view as bug list) | Environment: | |||||||||||
Last Closed: | 2016-11-04 05:20:51 UTC | Type: | --- | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Bug Depends On: | 773082 | ||||||||||||
Bug Blocks: | 530474, 1111320, 1280391, 1308852, 1310195, 1373526 | ||||||||||||
Attachments: |
|
Comment on attachment 1104205 [details]
0001-Added-mechanism-to-import-existing-CA-certificate.patch
The changes are 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.
*** Bug 1295831 has been marked as a duplicate of this bug. *** Per discussions in the RHEL 7.3 Triage meeting of 01/06/2016: priority high Fixed external CA case for IPA compatibility in master (edewata): * 449e4357e733a70e8f27f65f69ca8f0f7c8b5b21 Created attachment 1117380 [details]
pki-core-Added-mechanism-to-import-existing-CA-certificate.patch
The ticket has been implemented upstream in the following commits:
* 9dce4a497f7c977a3c453972706eeb325bd33275
* ec9c68d68eabff3784fcf6dabf2c6745734b3c9c
* 20c985ae773b26f653cac6d22bd9d93923e18c8e
* 3294f5087997427d060bce85d033652f7a8431da
* 449e4357e733a70e8f27f65f69ca8f0f7c8b5b21
* 66a4b7e635a4456a102221049c58c461d3429093
* 9609f4e6035d3cdff19a0f78caee2d08b095c8ba
These changes have been backported to RHEL 7.2 in the attached patch.
Comment on attachment 1117380 [details] pki-core-Added-mechanism-to-import-existing-CA-certificate.patch Tested out RHEL 7.2 patch by applying it to the DOGTAG_10_2_5_RHEL_BRANCH, building and installing the packages, creating a CA and successfully enrolling a certificate. Since this particular ticket is for RHEL 7.3 (awaiting a request for the RHEL 7.2 Z-Stream ticket), I checked and pushed this patch into the RHEL 7.3 Brew branch (but did not build since RHEL 7.3 will be based upon Dogtag 10.3 rather than 10.2.5) to allow this bug to be moved to MODIFIED: commit 206605e3239d62bd5bad943b8fff9e6e74ee838d Author: Matthew Harmsen <mharmsen> Date: Tue Feb 2 12:47:28 2016 -0700 Resolves: rhbz #1289323 - Bugzilla Bug #1289323 - [RFE] Provide the user the ability to import thei own CA certificate with private key [edewata] Created attachment 1120621 [details]
pki-core-Fixed-KRA-installation.patch
There's a problem in commit 66a4b7e635a4456a102221049c58c461d3429093 that caused KRA installation to fail. It has now been fixed in d42f39334ce4b4f5fa89707bfb6145039ff04579. The fix has been ported to RHEL 7.2 in the attached patch.
Created attachment 1120622 [details]
pki-core-Added-support-for-existing-CA-case.patch
This patch contains all changes for RHEL 7.2 which are based on these changes upstream:
* 9dce4a497f7c977a3c453972706eeb325bd33275
* ec9c68d68eabff3784fcf6dabf2c6745734b3c9c
* 20c985ae773b26f653cac6d22bd9d93923e18c8e
* 3294f5087997427d060bce85d033652f7a8431da
* 449e4357e733a70e8f27f65f69ca8f0f7c8b5b21
* 66a4b7e635a4456a102221049c58c461d3429093
* 9609f4e6035d3cdff19a0f78caee2d08b095c8ba
* d42f39334ce4b4f5fa89707bfb6145039ff04579
Comment on attachment 1117380 [details]
pki-core-Added-mechanism-to-import-existing-CA-certificate.patch
This patch was obsoleted by pki-core-Added-support-for-existing-CA-case.patch.
Comment on attachment 1120621 [details]
pki-core-Fixed-KRA-installation.patch
This patch was obsoleted by pki-core-Added-support-for-existing-CA-case.patch.
(In reply to Matthew Harmsen from comment #10) > Comment on attachment 1117380 [details] > pki-core-Added-mechanism-to-import-existing-CA-certificate.patch > > Tested out RHEL 7.2 patch by applying it to the DOGTAG_10_2_5_RHEL_BRANCH, > building and installing the packages, creating a CA and successfully > enrolling a certificate. > > Since this particular ticket is for RHEL 7.3 (awaiting a request for the > RHEL 7.2 Z-Stream ticket), I checked and pushed this patch into the RHEL 7.3 > Brew branch (but did not build since RHEL 7.3 will be based upon Dogtag 10.3 > rather than 10.2.5) to allow this bug to be moved to MODIFIED: > > commit 206605e3239d62bd5bad943b8fff9e6e74ee838d > Author: Matthew Harmsen <mharmsen> > Date: Tue Feb 2 12:47:28 2016 -0700 > > Resolves: rhbz #1289323 > > - Bugzilla Bug #1289323 - [RFE] Provide the user the ability to import > thei > own CA certificate with private key [edewata] commit ff6ff140d2f98864979f43bac078a9fe02d9c9d2 Author: Matthew Harmsen <mharmsen> Date: Tue Feb 2 17:54:58 2016 -0700 Resolves: rhbz #1289323 - Bugzilla Bug #1289323 - [RFE] Provide the user the ability to import their own CA certificate with private key [edewata] NOTE: This revised patch included an additional fix for KRA installation, and renamed 'pki-core-Added-mechanism-to-import-existing-CA-certificate.patch' to 'pki-core-Added-support-for-existing-CA-case.patch'. Verification steps: --------- On host 1 --------- 1. Create DS instance 2. Create CA deployment config (ca.cfg): [CA] pki_admin_email=caadmin pki_admin_name=caadmin pki_admin_nickname=caadmin pki_admin_password=Secret123 pki_admin_uid=caadmin pki_backup_keys=True pki_backup_password=Secret123 pki_client_database_password=Secret123 pki_client_database_purge=False pki_client_pkcs12_password=Secret123 pki_ds_base_dn=dc=ca,dc=example,dc=com pki_ds_database=ca pki_ds_password=Secret123 pki_security_domain_name=EXAMPLE pki_token_password=Secret123 3. Install CA: pkispawn -f ca.cfg -s CA 4. Export CA signing cert, key, and CSR: pki-server subsystem-cert-export ca signing --csr-file ca_signing.csr --pkcs12-file ca.p12 5. Copy ca_signing.crt and ca_signing.csr to /tmp on host 2 6. Export NSS db password: grep internal= /var/lib/pki/pki-tomcat/conf/password.conf | awk -F= '{print $2;}' > internal.txt 7. Note the key ID of the CA signing cert: certutil -K -d /var/lib/pki/pki-tomcat/alias/ -f internal.txt < 0> rsa 06b218333b1d518847bc6e16f584e3b91b1186b6 caSigningCert cert-pki-tomcat CA --------- On host 2 --------- 8. Create CA deployment config for step 1 (ca-step1.cfg): [CA] pki_admin_email=caadmin pki_admin_name=caadmin pki_admin_nickname=caadmin pki_admin_password=Secret123 pki_admin_uid=caadmin pki_backup_keys=True pki_backup_password=Secret123 pki_client_database_password=Secret123 pki_client_database_purge=False pki_client_pkcs12_password=Secret123 pki_ds_base_dn=dc=ca,dc=example,dc=com pki_ds_database=ca pki_ds_password=Secret123 pki_security_domain_name=EXAMPLE pki_token_password=Secret123 pki_external=True pki_external_step_two=False 9. Install CA step 1: pkispawn -f ca-step1.cfg -s CA 10. Create CA deployment config for step 2 (ca-step2.cfg): [CA] pki_admin_email=caadmin pki_admin_name=caadmin pki_admin_nickname=caadmin pki_admin_password=Secret123 pki_admin_uid=caadmin pki_backup_keys=True pki_backup_password=Secret123 pki_client_database_password=Secret123 pki_client_database_purge=False pki_client_pkcs12_password=Secret123 pki_ds_base_dn=dc=ca,dc=example,dc=com pki_ds_database=ca pki_ds_password=Secret123 pki_security_domain_name=EXAMPLE pki_token_password=Secret123 pki_external=True pki_external_step_two=True pki_external_csr_path=/tmp/ca_signing.csr pki_external_pkcs12_path=/tmp/ca.p12 pki_external_pkcs12_password=Secret123 11. Install CA step 2: pkispawn -f ca-step2.cfg -s CA 12. Export NSS db password: grep internal= /var/lib/pki/pki-tomcat/conf/password.conf | awk -F= '{print $2;}' > internal.txt 13. Verify that the key ID of the CA signing cert matches the one in step #7: certutil -K -d /var/lib/pki/pki-tomcat/alias/ -f internal.txt < 0> rsa 06b218333b1d518847bc6e16f584e3b91b1186b6 caSigningCert cert-pki-tomcat CA Note that the key ID of the other certificates will not match. Missing step: 7.5. Create DS instance on host 2 Pushed to DOGTAG_10_2_RHEL_BRANCH: commit b379df18acee997b34aed2eda76c556f520500c9 Author: Endi S. Dewata <edewata> Date: Thu Nov 12 00:23:26 2015 +0100 Added support for existing CA case. The deployment procedure for external CA has been modified such that it generates the CA CSR before starting the server. This allows the same procedure to be used to import CA certificate from an existing server. It also removes the requirement to keep the server running while waiting to get the CSR signed by an external CA. The pki ca-cert-request-submit command has been modified to provide options to specify the profile name and the CSR which will be used to create and populate the request object. This way it's no longer necessary to download the request template and insert the CSR manually. A new pki-server subsystem-cert-export command has been added to export a system certificate, the CSR, and the key. This command can be used to migrate a system certificate into another instance. The man page have been updated to reflect these changes. The installation code for external CA case has been fixed such that IPA can detect step 1 completion properly. The code that handles certificate data conversion has been fixed to reformat base-64 data for PEM output properly. The installation summary for step 1 has been updated to provide more accurate information. https://fedorahosted.org/pki/ticket/456 NOTE: This patch is also contained in the 'master', and will be overwritten when the re-base to 10.3.0 is performed. Addition QE test case (Note: this is different from the case when the CSR was freshly generated on the HSM for a more traditional external CA case): Test case: when the CA signing cert/keys are already in the HSM (it might have been moved from another HSM or it might just have been used in an older instance sharing the same HSM). In this case, 1.the new CA instance is expected to be instructed to use the existing CA signing cert nickname to get to the cert, and 2. the ca cert/chain are imported into the new instance's NSS softtoken with proper trust flags. Endi gave me the following link for reference: http://pki.fedoraproject.org/wiki/Installing_CA_with_Existing_CA_Certificate#Exporting_existing_CA_via_HSM (In reply to Matthew Harmsen from comment #10) > Comment on attachment 1117380 [details] > pki-core-Added-mechanism-to-import-existing-CA-certificate.patch > > Tested out RHEL 7.2 patch by applying it to the DOGTAG_10_2_5_RHEL_BRANCH, > building and installing the packages, creating a CA and successfully > enrolling a certificate. > > Since this particular ticket is for RHEL 7.3 (awaiting a request for the > RHEL 7.2 Z-Stream ticket), I checked and pushed this patch into the RHEL 7.3 > Brew branch (but did not build since RHEL 7.3 will be based upon Dogtag 10.3 > rather than 10.2.5) to allow this bug to be moved to MODIFIED: > > commit 206605e3239d62bd5bad943b8fff9e6e74ee838d > Author: Matthew Harmsen <mharmsen> > Date: Tue Feb 2 12:47:28 2016 -0700 > > Resolves: rhbz #1289323 > > - Bugzilla Bug #1289323 - [RFE] Provide the user the ability to import > thei > own CA certificate with private key [edewata] Moving back from MODIFIED --> POST *** Bug 1127838 has been marked as a duplicate of this bug. *** Hi Endi, I was trying this scenario with new builds what i saw below mentioned error in host2 installation. -------------------------------------------------------------------- pkispawn : INFO ....... importing CA signing CSR from /tmp/ca_signing.csr pkispawn : INFO ....... importing certificates and keys from /tmp/ca.p12 --------------- Import complete --------------- certutil: Could not find cert: caSigningCert cert-topology-02-CA-external CA : PR_FILE_NOT_FOUND_ERROR: File not found pkispawn : INFO ....... validating the signing certificate pkispawn : ERROR ....... pki-server subsystem-cert-validate return code: 1 pkispawn : ERROR ....... Cert ID: signing Nickname: caSigningCert cert-topology-02-CA-external CA Usage: SSLCA Token: Internal Key Storage Token Status: INVALID ----------------- Validation failed ----------------- pkispawn : DEBUG ....... Error Type: CalledProcessError pkispawn : DEBUG ....... Error Message: Command '['pki-server', 'subsystem-cert-validate', '-i', 'topology-02-CA-external', 'ca', 'signing']' returned non-zero exit status 1 pkispawn : DEBUG ....... File "/usr/sbin/pkispawn", line 528, in main scriptlet.spawn(deployer) File "/usr/lib/python2.7/site-packages/pki/server/deployment/scriptlets/configuration.py", line 283, in spawn verifier.verify_certificate('signing') File "/usr/lib/python2.7/site-packages/pki/server/deployment/pkihelper.py", line 4646, in verify_certificate stderr=subprocess.STDOUT) File "/usr/lib64/python2.7/subprocess.py", line 575, in check_output raise CalledProcessError(retcode, cmd, output=output) Installation failed: Command '['pki-server', 'subsystem-cert-validate', '-i', 'topology-02-CA-external', 'ca', 'signing']' returned non-zero exit status 1 ------------------------------------------------------------------------------ Then i check the certs data i get below result. on host 1: root@pki1 1289323]# pki-server subsystem-cert-show -i topology-02-CA ca signing --show-all Cert ID: signing Nickname: caSigningCert cert-topology-02-CA CA Token: Internal Key Storage Token Certificate: MIIDszCCApugAwIBAgIBATANBgkqhkiG9w0BAQsFADBIMSUwIwYDVQQKDBx0b3BvbG9neS0wMl9Gb29iYXJtYXN0ZXIub3JnMR8wHQYDVQQDDBZDQSBTaWduaW5nIENlcnRpZmljYXRlMB4XDTE2MDgxMDEwMDkzNloXDTM2MDgxMDEwMDkzNlowSDElMCMGA1UECgwcdG9wb2xvZ3ktMDJfRm9vYmFybWFzdGVyLm9yZzEfMB0GA1UEAwwWQ0EgU2lnbmluZyBDZXJ0aWZpY2F0ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMuJX2pWYwZPtkF5FvOD3tBMUFmOn99nHplZm1nEPszvLH1ZheDjZqtrIYAK4ZTZ4MjOLQG/N7SY85H3TNJEmNUvCnGn2OqDyH249z6D78w/XIma63rwB35aB3OQut+xzQ9g8uaqplgWAgCDAe9dIoJnhMxSB/wKq8CsKaJHx38wACUMbohCGcAlX/hQBQPspDJXdJu2b3qqcn/Gwcx4RJlnHaxKMOZKSe9VtxAwRKBZTDV6HKz/daNjmVOmgkFANGR6SlEoJfiKZkyigmdExXCqWusMkD8QlBtdS3X04v4MdACKNwxj5AdT7e6I/xDaSBNM659sOT71icCpwSjLAR0CAwEAAaOBpzCBpDAfBgNVHSMEGDAWgBQweIv0jBDv3+MqjfI+ts4BOGIwFTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBxjAdBgNVHQ4EFgQUMHiL9IwQ79/jKo3yPrbOAThiMBUwQQYIKwYBBQUHAQEENTAzMDEGCCsGAQUFBzABhiVodHRwOi8vcGtpMS5leGFtcGxlLmNvbToyMDA4MC9jYS9vY3NwMA0GCSqGSIb3DQEBCwUAA4IBAQAbI/kwL4WNAs3y7RI/qZbHAjQMJKtNOi6yBarglPEgaPmqnkLMTFkTGnWNlvsjCO5VMNasfzZrN7Z4FIf3SxKioZ3sSoY0wrxNlI2ueaxPvmhvNZWY9kuRKk2DssxD/P2oMfeouB8rpgWKtNlt7gBvv3lDHQjxYQNqemt+PjAFWABw1yt/cgfMORuK//LGaMUI6IpV5cLveMylUCArKj6gmo2/BVGh58Va20hkycM4zXtF37efdunu1qcD3u9fM4uR22RyVQnfaQdaOGhg7iq8ZPWx4p6kezcqBDf1IdqH/ReJVE6bMotu90sSYF1856batp0v/an2UPiQ6GdtCmv+ Request: MIICvzCCAacCAQAwSDElMCMGA1UECgwcdG9wb2xvZ3ktMDJfRm9vYmFybWFzdGVyLm9yZzEfMB0GA1UEAwwWQ0EgU2lnbmluZyBDZXJ0aWZpY2F0ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMuJX2pWYwZPtkF5FvOD3tBMUFmOn99nHplZm1nEPszvLH1ZheDjZqtrIYAK4ZTZ4MjOLQG/N7SY85H3TNJEmNUvCnGn2OqDyH249z6D78w/XIma63rwB35aB3OQut+xzQ9g8uaqplgWAgCDAe9dIoJnhMxSB/wKq8CsKaJHx38wACUMbohCGcAlX/hQBQPspDJXdJu2b3qqcn/Gwcx4RJlnHaxKMOZKSe9VtxAwRKBZTDV6HKz/daNjmVOmgkFANGR6SlEoJfiKZkyigmdExXCqWusMkD8QlBtdS3X04v4MdACKNwxj5AdT7e6I/xDaSBNM659sOT71icCpwSjLAR0CAwEAAaAyMDAGCSqGSIb3DQEJDjEjMCEwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAcYwDQYJKoZIhvcNAQELBQADggEBAAsj4eKFMMPRA1p30aNWm7MKknYu6H2UmWlRgKw7SncWoWNNYubwQCOVWoPTt5U5W+kfCn1MW/mIPuCkxVwpSPqZcqcu5FS66T4ECxcwTn1PtZsTgNH7k8Pub8eT0qauNv0tQ2M7Hs3CWLlTa80X5oZ7L6TtcUnTGbgLNKxhBv15LEmgMf9qLGTusz5ipq4mcLnWhuG83iFSV9vjQQfgvxeVb7hvhuVARnePpxcWH6BcpzD5g3H3dOWPvaDBZgLbjrNQx14UrteG4lYhBoD/rNBjR2o4bGiRXwKGGtKsbAZuxFf/VfNx1HGhs08AyJdTFJoUgkux9a5C742LD9ghb+w= on host 2: [root@pki2 BZ]# pki-server subsystem-cert-show -i topology-02-CA-external ca signing --show-all Cert ID: signing Nickname: caSigningCert cert-topology-02-CA CA Token: Internal Key Storage Token Certificate: None Request: MIICvjCCAaYCAQAwRzEkMCIGA1UECgwbZXhhbXBsZS5jb20gU2VjdXJpdHkgRG9tYWluMR8wHQYDVQQDDBZDQSBTaWduaW5nIENlcnRpZmljYXRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx6glJMjZ3QkllRqg/m1JHVhcUCwOJbJn7G9diYmmGIwUrM2duOVFkKDelRpyoDfW1LXL4JFRV6a3QRCO3RveQ7O3tReD7iPANMd2rllksc5izqVuR2hnX/MReJsd0Z1AzZ1hflWscPtlmH5DrnzR/vaXfu5b31wcQVjl8zP4jQ2ZjC4q56GhJCAW+IgzcEN+UPFRvxbON5DsbJIo2t/ueVtj22hjQOlW4/FDxYlgVHLceXDh/qCNqBe4f2AAMxvwNjODNVdS86v+dy9RLjq3vFfcbi+2c/vLh6SmC5jbo+Wzd8X6iha0nPLF+u6tooNTop3DbA3OoLEHDo+q+Z0qmwIDAQABoDIwMAYJKoZIhvcNAQkOMSMwITAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBxjANBgkqhkiG9w0BAQsFAAOCAQEAZzonAnfBzKpb82hHaYrFzifTHteLA2YsYV+PGr6GjJWYIMccgznmkjzw3j+4g2NdXrKhoqK4htAMRcHUqLPfxhl0WK36Imq7ZHt52RB4AkSClGuQywaCzYPBLcisYTb1Fi4MDPHANW5U3WDoIRPoOKdn0vtCcTOGUKwqsdIlYJnrkqQS/hY4qz+Y4T/AKVM/Yd31pjfsHMspB44aiBKsRDEkHM6wQBs0EpA7JcKBSnbuP/AaiT10e0DfgRbMCFHp1jPQSH6Ok1pSNx3lwKHG5hEUgqL3EbiVP8pk0D6uy4D/JhpjRe3XkuO70UgixAYBq3nnPtM2y0CKyMynsfW5Mg== Hi Geetika, Could you attach the files you used for host2: pkispawn config, PKCS #12 file, CSR, and external certs (if any)? Thanks. Build ::10.3.3-5.el7 Verified using http://pki.fedoraproject.org/wiki/Installing_CA_with_Existing_CA_Certificate_using_PKCS12_File According to wiki page , we are doing below steps but I have one question here. 1. I create the csr generated using new procedure: =============================================== $ echo "-----BEGIN NEW CERTIFICATE REQUEST-----" > ca_signing.csr $ grep ca.signing.certreq /var/lib/pki/pki-tomcat/ca/conf/CS.cfg | awk -F= '{print $2;}' >> ca_signing.csr $ echo "-----END NEW CERTIFICATE REQUEST-----" >> ca_signing.csr 2. I got below mentioned csr:: ============================ [root@pki1 1289323]# cat ca_signing.csr -----BEGIN NEW CERTIFICATE REQUEST----- MIICvzCCAacCAQAwSDElMCMGA1UECgwcdG9wb2xvZ3ktMDJfRm9vYmFybWFzdGVyLm9yZzEfMB0GA1UEAwwWQ0EgU2lnbmluZyBDZXJ0aWZpY2F0ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMuJX2pWYwZPtkF5FvOD3tBMUFmOn99nHplZm1nEPszvLH1ZheDjZqtrIYAK4ZTZ4MjOLQG/N7SY85H3TNJEmNUvCnGn2OqDyH249z6D78w/XIma63rwB35aB3OQut+xzQ9g8uaqplgWAgCDAe9dIoJnhMxSB/wKq8CsKaJHx38wACUMbohCGcAlX/hQBQPspDJXdJu2b3qqcn/Gwcx4RJlnHaxKMOZKSe9VtxAwRKBZTDV6HKz/daNjmVOmgkFANGR6SlEoJfiKZkyigmdExXCqWusMkD8QlBtdS3X04v4MdACKNwxj5AdT7e6I/xDaSBNM659sOT71icCpwSjLAR0CAwEAAaAyMDAGCSqGSIb3DQEJDjEjMCEwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAcYwDQYJKoZIhvcNAQELBQADggEBAAsj4eKFMMPRA1p30aNWm7MKknYu6H2UmWlRgKw7SncWoWNNYubwQCOVWoPTt5U5W+kfCn1MW/mIPuCkxVwpSPqZcqcu5FS66T4ECxcwTn1PtZsTgNH7k8Pub8eT0qauNv0tQ2M7Hs3CWLlTa80X5oZ7L6TtcUnTGbgLNKxhBv15LEmgMf9qLGTusz5ipq4mcLnWhuG83iFSV9vjQQfgvxeVb7hvhuVARnePpxcWH6BcpzD5g3H3dOWPvaDBZgLbjrNQx14UrteG4lYhBoD/rNBjR2o4bGiRXwKGGtKsbAZuxFf/VfNx1HGhs08AyJdTFJoUgkux9a5C742LD9ghb+w -----END NEW CERTIFICATE REQUEST----- 3. I tried to decode the csr using openssl and other online utilities: -- Didn't work as expected(decode is not possible) =================================================================== openssl req -in ca_signing.csr -noout -text unable to load X509 request 140246319929248:error:0906D064:PEM routines:PEM_read_bio:bad base64 decode:pem_lib.c:812: ==> Question: What is the use of generating this csr we are not using it anywhere.??? While doing installation on another host we are independently creating a csr. request. Hi Endi, with HSM it failed.In nssdb i could see: root@csqa1 geetika_test # grep "caSigningCert cert-RootCA CA" certs caSigningCert cert-RootCA CA CTu,Cu,Cu NHSM6000:caSigningCert cert-RootCA CA CTu,Cu,Cu root@csqa1 geetika_test # certutil -L -d /var/lib/pki/RootCA/alias/ -h nfast -------------------------------------------------------------------- Failure: pkispawn : INFO ....... importing CA signing CSR from ca_signing.csr certutil: Could not find cert: caSigningCert cert-RootCA CA : PR_FILE_NOT_FOUND_ERROR: File not found pkispawn : INFO ....... validating the signing certificate pkispawn : ERROR ....... pki-server subsystem-cert-validate return code: 1 pkispawn : ERROR ....... Cert ID: signing Nickname: caSigningCert cert-RootCA CA Usage: SSLCA Token: NHSM6000 Status: INVALID ----------------- Validation failed ----------------- pkispawn : DEBUG ....... Error Type: CalledProcessError pkispawn : DEBUG ....... Error Message: Command '['pki-server', 'subsystem-cert-validate', '-i', 'RootCA-extrenal', 'ca', 'signing']' returned non-zero exit status 1 pkispawn : DEBUG ....... File "/usr/sbin/pkispawn", line 528, in main scriptlet.spawn(deployer) File "/usr/lib/python2.7/site-packages/pki/server/deployment/scriptlets/configuration.py", line 283, in spawn verifier.verify_certificate('signing') File "/usr/lib/python2.7/site-packages/pki/server/deployment/pkihelper.py", line 4646, in verify_certificate stderr=subprocess.STDOUT) File "/usr/lib64/python2.7/subprocess.py", line 575, in check_output raise CalledProcessError(retcode, cmd, output=output) Installation failed: Command '['pki-server', 'subsystem-cert-validate', '-i', 'RootCA-extrenal', 'ca', 'signing']' returned non-zero exit status 1 Geetika, I'm not sure why CSR is invalid in comment #28. Please open a separate ticket. There are tickets to investigate how the CSR in CS.cfg is actually used, and whether it's actually necessary to store it in in CS.cfg: * https://fedorahosted.org/pki/ticket/1165 * https://fedorahosted.org/pki/ticket/1552 Until then the CSR in CS.cfg should be preserved during migration to a new instance. About the error in comment #29, it looks like you are using different names for the instances (i.e. RootCA and RootCA-extrenal). Could you try using the same instance name? The certificate nicknames by default contain the instance name, so the new instance might not be able to find the existing certificate correctly if the instance names are different. Hello Endi, I have a raised a BZ for incorrect csr generation using CS.cfg. Bug 1366578 - CSR Generated is not of correct format hence unable to decode In my configuration file i have used Below mentioned config.So here i have changed the certs nickname but i still see failure.I am trying to migrate certs on instance with different instance name.So if i externally setting nickname i thought it should work. pki_ca_signing_nickname=caSigningCert cert-RootCA CA pki_ssl_server_nickname=Server-Cert cert-RootCA pki_subsystem_nickname=subsystemCert cert-RootCA pki_ocsp_signing_nickname=ocspSigningCert cert-RootCA CA pki_audit_signing_nickname=auditSigningCert cert-RootCA CA pki_ssl_server_nickname=Server-Cert cert-RootCA pki_subsystem_nickname=subsystemCert cert-RootCA Geetika, It looks like the CA signing certificate nickname (pki_ca_signing_nickname) needs to match the existing certificate because it will be reused. However, the other system certificate nicknames must be different from the existing certificates because the server will create new ones. I've updated the documentation: http://pki.fedoraproject.org/wiki/Installing_CA_with_Existing_CA_Certificate_using_Certificate_File Please try again. Thanks. Test Environment : ------------------------ 1. Internal Key Storage Token 2. HSM Test Case 1 : To test certs and key import for HSM. ------------------------------------------------------------------- I think we can't test this scenario because we cannot extract private keys from HSM .We can't test a scenario here where we migrate both key and cert to another HSM. So I am not sure if this is a potential test case . Test Case 2: To test certs and key import using internal token ------------------------------------------------------------------------------- 1. with new CA 2, with existing CA 3. with externally signed CA 4. with SuBCA. 5. with chains of external CA(mixed combination of dogtag,openssl,nssdb) Another question that i have is :: ----------------------------------- 1. We have something called serial/request start range and stop.So if we have removed the instance and we try to re-use these ranges can we do that?? pki_serial_number_range_start=... pki_request_number_range_start=... 2. Logs are bit confusing when it says "deleteCert Exception=java.io.IOException: The certificate with the same nickname: NHSM6000:ocspSigningCert cert-NHSM-Test CA has been found on HSM. " <debug log snip> 1450 [17/Aug/2016:06:17:45][http-bio-22443-exec-3]: ConfigurationUtils: findCertificate: The certificate with the same nickname: NHSM6000:ocspSigningCert cert-NHSM-Test CA has been found on HSM. Please remove it before proceeding. 1451 [17/Aug/2016:06:17:45][http-bio-22443-exec-3]: handleCerts(): deleteCert Exception=java.io.IOException: The certificate with the same nickname: NHSM6000:ocspSigningCert cert-NHSM-Test CA has been found on HSM. Please remove it before proceeding. 1452 [17/Aug/2016:06:17:45][http-bio-22443-exec-3]: handleCerts(): Failed to import user certificate.org.mozilla.jss.crypto.TokenException: PK11_ImportDERCertForKey Unable to import certificate to its token: (-8054) You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert. </debug log sinp> What my observation is certs are not removed we just create a new cert with different keyid. Another observation : Procedure mentioned in http://pki.fedoraproject.org/wiki/Installing_with_Externaly-Signed_CA_Certificate If i try using 2 step setup(external CA) i always faced issues that i have mentioned in comment #29 Geetika, I think you'd need to specify a new serial/request starting numbers if you're using HSM or if you migrate the database to prevent conflicts with existing certificates/requests. The doc has been updated to clarify this: http://pki.fedoraproject.org/wiki/Installing_CA_with_Existing_CA_Certificate_using_Certificate_File Please open a separate ticket to improve the log messages. I'd suggest you open a separate ticket for each case that has a problem. It's a bit confusing to investigate various cases under the same ticket, and some cases might have different priorities. This particular ticket covers the basic case without HSM described in comment #19. If that case works I'd suggest closing the ticket and we continue in new tickets for the other cases. Thanks. Test case : 1. To verify the rsa keyid for non hsm installation-- PASS Keyid is same after migration. Test case specified in comment#19 works as expected. I'll/ have opened separate BZ for new issues .This has been tested purely without HSM as mentioned in comment #19. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2396.html |
Created attachment 1104205 [details] 0001-Added-mechanism-to-import-existing-CA-certificate.patch This patch contains the combined changes for ticket #456 that has been backported to DOGTAG_10_2_5_RHEL_BRANCH: * 9dce4a497f7c977a3c453972706eeb325bd33275 * ec9c68d68eabff3784fcf6dabf2c6745734b3c9c * 20c985ae773b26f653cac6d22bd9d93923e18c8e * 3294f5087997427d060bce85d033652f7a8431da