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...
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.