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(a)nthpermutation.com>
Sent: Monday, April 05, 2010 8:31 PM
To: "Arshad Noor" <arshad.noor(a)strongauth.com>
Cc: <pki-users(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-users