So, we can only use indirect crl if it was issued by a CRL issuer with the same
identity name as the CA?
Is there a way to have one indirect CRL issuer produce a crl for many
intermediate CAs (to potentially revoke the CA certificates as well as the EE
certs that they sign)?
Ideally, we would like to have our PKI segmented into several layers of CAs
each with different administrative rights (implemented via custom extensions as
well as name-constraints). The root CA key is kept offline. It has signed
several first level CAs, each with distinct purposes. These, in-turn have
signed some subordinate CAs which are in daily use -- the first level CAs are
also offline but each controlled by their own department head. It would be
nice to have ONE indirect crl signer, signed by the root CA and referenced in
all CA's crldp, so that we can produce timely CRLs with only a single key (ALL
keys are kept on smartcards).
Is verification with indirect revocation like this possible without custom
verification code in 1.0.0d? If so, could someone please post example ca
certificates or at least explain what is checked in verify when searching the
stack for a suitable indirect crl?
Thanks!
Adam
________________________________________
From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] On
Behalf Of Jeff Saremi [jsar...@morega.com]
Sent: Thursday, March 17, 2011 3:01 PM
To: openssl-users@openssl.org
Subject: Re: Handling Indirect CRL Issuer
With great many thanks to Dr. Henson for not only responding to every
post I have had so far but also for providing solid guidance on how to
address the problem leading to the heading of this thread, I am adding
some extra material and some verbatim quotes from Dr. Henson here so
that they might be of some benefit to some one.
> What you do is to generate a CRL issuing certificate which has exactly the
> same subject, issuer name as the CA. In that certificate include a keyUsage
> extension with only the crl signing bit asserted. If you had the option the CA
> certificate should have keyUsage and certsign but NOT crl sign set.
>
> You then issue CRLs from this second certificate which will have a different
> AKID. Then OpenSSL will use that certificate (if it can find it) instead of
> the CA certificate.
To create a second certificate duplicating an existing one completely
you may face some challenges, but the following two commands should
help. Also you may want to possibly use "-preserveDN" command line
option as well as setting "preserve=yes" in your config file:
> openssl x509 -in cert.pem -signkey newkey.pem -out newcert.pem
>
> This should convert an existing certificate into a self signed version with a
> new key. From there you can convert it into a certificate request with:
>
> openssl x509 -in newcert.pem -x509toreq -signkey newkey.pem
Also make sure you create those AuthorityKeyIdentifiers in your
certs/crls by having lines like the following in appropriate places in
your config:
authorityKeyIdentifier=keyid,issuer:always
Finally, let's assume you are in possession of your 2nd certificate (or
the Indirect CRL Issuer's certificate). For this to be processed
properly you would need to add it to X509_STORE_CTX as an "untrusted"
cert. Setting it along with your trust chain certs won't work.
To do that and since I had to do this in the context of an SSL
connection, I decided to use a callback like the following:
a) create an "app verify cert" callback:
int appVerifyCallback(X509_STORE_CTX *ctx,void *arg)
{
STACK_OF(X509*) untrustedStack = sk_X509_new_null();
// add your "untrusted" certs such as the 2nd CA cert
// or your Indirect CRL Issuer to the stack
X509 *cert = ...
sk_X509_push(untrustedStack, cert);
// this call sets the ctx->untrusted
X509_STORE_CTX_set_chain(ctx, untrustedStack);
return 1;
}
b) add this to your SSL context:
SSL_CTX_set_cert_verify_callback(mCtx,
&appVerifyCallback,
(void*)untrustedCerts);
And you should be all set to validate those certs and CRLs.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
