Bug 1289323 - [RFE] Provide the user the ability to import their own CA certificate with private key
[RFE] Provide the user the ability to import their own CA certificate with pr...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pki-core (Show other bugs)
7.3
Unspecified Unspecified
high Severity high
: rc
: 7.3
Assigned To: Endi Sukma Dewata
Asha Akkiangady
Marc Muehlfeld
: FutureFeature, ZStream
: 1127838 1295831 (view as bug list)
Depends On: 773082
Blocks: 530474 1280391 1373526 1111320 1308852 1310195
  Show dependency treegraph
 
Reported: 2015-12-07 16:04 EST by Endi Sukma Dewata
Modified: 2016-11-04 01:20 EDT (History)
14 users (show)

See Also:
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 01:20:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
0001-Added-mechanism-to-import-existing-CA-certificate.patch (61.06 KB, patch)
2015-12-09 22:51 EST, Endi Sukma Dewata
no flags Details | Diff
pki-core-Added-mechanism-to-import-existing-CA-certificate.patch (65.11 KB, patch)
2016-01-22 20:32 EST, Endi Sukma Dewata
mharmsen: review+
Details | Diff
pki-core-Fixed-KRA-installation.patch (3.83 KB, patch)
2016-02-02 19:35 EST, Endi Sukma Dewata
no flags Details | Diff
pki-core-Added-support-for-existing-CA-case.patch (65.11 KB, patch)
2016-02-02 19:39 EST, Endi Sukma Dewata
no flags Details | Diff

  None (edit)
Comment 1 Endi Sukma Dewata 2015-12-09 22:51 EST
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
Comment 2 Endi Sukma Dewata 2015-12-17 13:40:18 EST
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.
Comment 3 Endi Sukma Dewata 2016-01-06 15:31:34 EST
*** Bug 1295831 has been marked as a duplicate of this bug. ***
Comment 4 Matthew Harmsen 2016-01-06 20:59:05 EST
Per discussions in the RHEL 7.3 Triage meeting of 01/06/2016: priority high
Comment 5 Matthew Harmsen 2016-01-19 15:01:07 EST
Fixed external CA case for IPA compatibility in master (edewata):

    * 449e4357e733a70e8f27f65f69ca8f0f7c8b5b21
Comment 8 Endi Sukma Dewata 2016-01-22 20:32 EST
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 10 Matthew Harmsen 2016-02-02 14:54:23 EST
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@redhat.com>
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]
Comment 12 Endi Sukma Dewata 2016-02-02 19:35 EST
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.
Comment 13 Endi Sukma Dewata 2016-02-02 19:39 EST
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 14 Matthew Harmsen 2016-02-02 19:46:39 EST
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 15 Matthew Harmsen 2016-02-02 19:47:05 EST
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.
Comment 16 Matthew Harmsen 2016-02-02 19:59:50 EST
(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@redhat.com>
> 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@redhat.com>
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'.
Comment 19 Endi Sukma Dewata 2016-02-17 22:45:15 EST
Verification steps:

---------
On host 1
---------

1. Create DS instance
2. Create CA deployment config (ca.cfg):

[CA]
pki_admin_email=caadmin@example.com
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@example.com
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@example.com
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.
Comment 20 Endi Sukma Dewata 2016-02-17 22:47:45 EST
Missing step:
7.5. Create DS instance on host 2
Comment 21 Matthew Harmsen 2016-02-19 19:30:17 EST
Pushed to DOGTAG_10_2_RHEL_BRANCH:

commit b379df18acee997b34aed2eda76c556f520500c9
Author: Endi S. Dewata <edewata@redhat.com>
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.
Comment 22 Christina Fu 2016-03-14 17:26:03 EDT
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
Comment 23 Matthew Harmsen 2016-03-29 17:17:08 EDT
(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@redhat.com>
> 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
Comment 24 Endi Sukma Dewata 2016-04-21 18:11:12 EDT
*** Bug 1127838 has been marked as a duplicate of this bug. ***
Comment 26 Geetika Kapoor 2016-08-10 08:33:25 EDT
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==
Comment 27 Endi Sukma Dewata 2016-08-10 11:23:58 EDT
Hi Geetika,

Could you attach the files you used for host2: pkispawn config, PKCS #12 file, CSR, and external certs (if any)? Thanks.
Comment 28 Geetika Kapoor 2016-08-11 02:12:11 EDT
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.
Comment 29 Geetika Kapoor 2016-08-11 08:22:25 EDT
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
Comment 30 Endi Sukma Dewata 2016-08-11 14:46:12 EDT
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.
Comment 31 Geetika Kapoor 2016-08-16 02:21:44 EDT
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
Comment 32 Endi Sukma Dewata 2016-08-16 15:31:03 EDT
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.
Comment 33 Geetika Kapoor 2016-08-17 07:33:19 EDT
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.
Comment 34 Geetika Kapoor 2016-08-17 08:02:39 EDT
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
Comment 35 Endi Sukma Dewata 2016-08-17 19:31:45 EDT
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.
Comment 36 Geetika Kapoor 2016-08-24 00:38:18 EDT
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.
Comment 42 errata-xmlrpc 2016-11-04 01:20:51 EDT
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

Note You need to log in before you can comment on or make changes to this bug.