Hi Mike, You mention that 2) The PKCS7 chain for step 2 is base 64 encoded, but NOT armored. What do you mean by "Not armored"? Thanks, Erwin -------------------------------------------------- From: "Michael StJohns" <msj@nthpermutation.com> Sent: Monday, April 05, 2010 8:31 PM To: "Arshad Noor" <arshad.noor@strongauth.com> Cc: <pki-users@redhat.com> Subject: Re: [Pki-users] Creating a sub-ca under an external CA?
OK - just for the record - I did figure out the problem. Here are the notes I have from this process.
1) AKI at the root doesn't matter 2) The PKCS7 chain for step 2 is base 64 encoded, but NOT armored. This needs to be documented - ideally in the box used to paste the chain. 3) The chain does not need to include the current (new cert), just the chain of certs for the issuing CA. 4) When the setup routine generates the subsidiary certificates - including the server cert - it appears to use the name in the certificate request as the issuer name for the subsidiary certificates, rather than the subject name of the cert issued by the superior CA. This was the thing that was causing me problems - my certificate signing tool was re-writing the requested name to add things like the country code and the subsidiary certs couldn't chain because of a name mismatch.
I think (4) is actually a bug in Dogtag - but I need to do some code reading to confirm my analysis. AFAIK the name in a CSR is just the proposed name - the issuing CA has every right to change the name to meet its requirements.
Thanks for the help...
Mike
On 4/4/2010 9:43 PM, Michael StJohns wrote:
On 4/4/2010 6:37 PM, Arshad Noor wrote:
I believe your problem may be due to the fact that your self-signed Root CA certificate does not contain the AuthorityKeyIdentifier (AKI) extension - it only has the SubjectKeyIdentifier (SKI) extension.
I tried issuing a new root cert with the AKI (and then doing a rebuild of the whole CA) - no luck. But thanks for the suggestion.
But - I did find out why my chain wasn't being accepted. It turns out that even though step 3 requires an armored Base64 value (e.g. -----BEGIN CERTIFICATE----- -----END CERTIFICATE-----), step 2 only wants the unarmored Base64 value of the PKCS7 chain object. It also doesn't appear to care whether or not the chain contains the new CA certificate for this instance. At least now the certs are ending up in the database even if the chains still don't seem to work.
_______________________________________________ Pki-users mailing list Pki-users@redhat.com https://www.redhat.com/mailman/listinfo/pki-users