[Pki-devel] [PATCH] Implemented ability to use an external CA
Matthew Harmsen
mharmsen at redhat.com
Thu Dec 6 22:37:29 UTC 2012
A revised patch has been attached to this email which addresses all of
the issues below.
All tests documented below have been run successfully against this patch.
NOTE: The tests have been modified slightly to comply with the latest
PKI source code.
On 12/05/12 10:32, Ade Lee wrote:
> Comments:
> 1. In pkiparser, you add:
> if not len(config.pki_master_dict['pki_security_domain_name']):
> config.pki_master_dict['pki_security_domain_name'] =\
> "External CA Security Domain"
>
> We no longer distinguish security domains like this. The default as
> defined by interpolation is fine.
>
> 2. I think we can remove the comment:
> # always set 'pki_skip_installation' true using a 'string'
> in initialization.py
>
> 3. In pkijython.py, you do:
> elif config.str2bool(self.master['pki_external']) and\
> config.str2bool(self.master['pki_external_step_two']):
> # always remove pki_external DS data from external CA step 1
> data.setRemoveData("true")
>
> This means that we'll set up the database and then blow it away and set
> it up again in step 2. Even more troubling, the request for the CA cert
> is probably stored in the database during step 1 and is blown away in
> step 2.
>
> The better way to do this would be to modify the configuration servlet
> to skip database population if we are doing external CA step 2.
>
> 4. In pkijython.py, you extract the pin from CS.cfg and overwrite the
> existing pin. But perhaps a better thing to do would be to move this
> code to pkiparser where the original pin is generated.
>
> Ade
>
> On Tue, 2012-12-04 at 22:31 -0800, Matthew Harmsen wrote:
>> The attached patch addresses the following PKI issues:
>> * TRAC Ticket #231 - Dogtag 10: Update PKI Deployment to handle
>> external CA
>> This code has been successfully tested on a slightly earlier version
>> of the source tree, although the attached patch has been re-based to
>> the 'master'.
>>
>> To test this code, the following procedure was followed on an x86_64
>> machine running 64-bit Fedora 18:
>> * First, a standard CA was created to be used as an "External
>> CA" using the following command and file ('# mv typescript
>> typescript.external' once finished):
>> * script -c 'pkispawn -s CA -f /tmp/pki/external.cfg
>> -vvv'
>>
>> # cat external.cfg
>> [Common]
>> pki_admin_password=<password>
>> pki_backup_password=<password>
>> pki_client_pkcs12_password=<password>
>> pki_ds_password=<password>
>> pki_security_domain_password=<password>
pki_http_port=18080
pki_https_port=18443
pki_instance_name=pki-external-tomcat
>> [Tomcat]
>> pki_ajp_port=18009
>> pki_tomcat_server_port=18005
>>
>> * Next, Step 1 for a CA which depended upon this External CA was
>> created using the following command and file ('# mv typescript
>> typescript.step_1' once finished):
>> * script -c 'pkispawn -s CA -f /tmp/pki/ca_1.cfg -vvv'
>>
>> # cat ca_1.cfg
>> [Common]
>> pki_admin_password=<password>
>> pki_backup_password=<password>
>> pki_client_pkcs12_password=<password>
>> pki_ds_password=<password>
>> pki_security_domain_password=<password>
>> [CA]
>> pki_external=True
>> pki_external_csr_path=/tmp/pki/config/ca_signing.csr
pki_ca_signing_subject_dn=CA Signing
Certificate,o=%{pki_security_domain_name)s External
>>
>> * Next, the CSR contained in the file '/tmp/pki/ca_signing.csr'
>> was utilzed to create a certificate using the "External CA"
>> using the following procedure:
>> * External CA:
>>
>> EE: Enrollment/Renewal Tab
>> * Use 'Manual Certificate Manager Signing
>> Certificate Enrollment'
>>
>> AGENT: Approve request by pressing 'submit'
>>
>> EE: Retrieval Tab
>> * Use 'Check Request Status' to obtain the
>> base 64 encoded certificate
>> * Store this blob into the file specified by
>> the value of 'pki_external_ca_cert_path' in ca_2.cfg
>>
>> EE: Retrieval Tab
>> * Use 'Import CA Certificate Chain' and select
>> the radio button entitled 'Display certificates in the
>> CA certificate chain for
>> importing individually into a server' to
>> obtain the base 64 encoded certificate chain
>> * Store this blob into the file specified by
>> the value of 'pki_external_ca_cert_chain_path' in
>> ca_2.cfg
>>
>> * Finally, Step 2 for a CA which depended upon this External CA
>> was created using the following command and file ('# mv
>> typescript typescript.step_2' once finished):
>> * script -c 'pkispawn -s CA -f /tmp/pki/ca_2.cfg -vvv'
>>
>> # cat ca_2.cfg
>> [Common]
>> pki_admin_password=<password>
>> pki_backup_password=<password>
>> pki_client_pkcs12_password=<password>
>> pki_ds_password=<password>
>> pki_security_domain_password=<password>
>> [CA]
>> pki_external=True
>> pki_external_ca_cert_chain_path=/tmp/pki/config/ca_signing_chain.cert
>> pki_external_ca_cert_path=/tmp/pki/config/ca_signing.cert
>> pki_external_step_two=True
pki_ca_signing_subject_dn=CA Signing
Certificate,o=%{pki_security_domain_name)s External
>>
>> _______________________________________________
>> Pki-devel mailing list
>> Pki-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/pki-devel
>
* Additionally, as a final sanity test, a default KRA was created
re-utilizing the 'ca_1.cfg' file ('# mv typescript typescript.kra'
once finished):
o script -c 'pkispawn -s KRA -f /tmp/pki/ca_1.cfg -vvv'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20121206/bd9b340a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20121206-Implemented-ability-to-utilize-an-external-CA.patch
Type: text/x-patch
Size: 21847 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20121206/bd9b340a/attachment.bin>
More information about the Pki-devel
mailing list