RE: Handling Indirect CRL Issuer
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 Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
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 Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Handling Indirect CRL Issuer
Does anyone have an example of how an indirect CRL issuer is handled? This is my understanding of needs to be done. If at least someone could verify that, I'd be really appreciative: 1. download the CRL 2. If not indirect, handle as usual (let's pretend for now that we know how to handle these in OpenSSL) 3. If Indirect flag is set, check Authority Information Access. (possibly using something like: AUTHORITY_INFO_ACCESS *info = (AUTHORITY_INFO_ACCESS*) X509_CRL_get_ext_d2i(crl, NID_info_access, NULL, NULL);) 4. Download the issuer's certificate using the URL above. 5. Add the cert to the store? (using X509_STORE_add_cert()?) Any other steps? thanks jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Handling Indirect CRL Issuer
On Thu, Mar 17, 2011, Jeff Saremi wrote: Does anyone have an example of how an indirect CRL issuer is handled? This is my understanding of needs to be done. If at least someone could verify that, I'd be really appreciative: 1. download the CRL 2. If not indirect, handle as usual (let's pretend for now that we know how to handle these in OpenSSL) 3. If Indirect flag is set, check Authority Information Access. (possibly using something like: AUTHORITY_INFO_ACCESS *info = (AUTHORITY_INFO_ACCESS*) X509_CRL_get_ext_d2i(crl, NID_info_access, NULL, NULL);) 4. Download the issuer's certificate using the URL above. 5. Add the cert to the store? (using X509_STORE_add_cert()?) First thing: do you need to worry about indirect CRLs: they are pretty rare outside compliance tests. Indirect CRLs are not supported unless an explicit flag is set btw: this is due to unresolved security issues in the standards. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Handling Indirect CRL Issuer
It looks like we need to support indirect CRL Issuers at least for CRL's
issued for ourselves.
I have done most of the work. It looks I don't quite know how to
generate CRLs with the indirect CRL issuer or I don't know how to
generate the CRL issuer's certificate using the root certificate.
So I have added the CRL issuer's cert to the trusted ones. But when I'm
trying to use the CRL i get stopped here:
crl_akid_check()
{
...
if(X509_check_akid()
// this is where if fails
and inside X509_check_akid()
...
/* Check key ids (if present) */
if(akid-keyid issuer-skid
ASN1_OCTET_STRING_cmp(akid-keyid, issuer-skid) )
return X509_V_ERR_AKID_SKID_MISMATCH;
There's definitely something I don't know about AKID's and how to set
them properly.
To help you out here are the certificates and CRLs (i have masked some
fields):
*** Our ROOT cert *
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=TestMoregaRootCA, C=CA, O=TestMorega
Validity
Not Before: Jun 8 00:29:30 2010 GMT
Not After : Jun 3 00:29:30 2030 GMT
Subject: CN=TestMoregaRootCA, C=CA, O=TestMorega
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
...
6c:68:70:a5:c1:7e:5e:b8:e4:82:ff:6d:c6:3
X509v3 extensions:
X509v3 Subject Key Identifier:
70:8F:22:BC:D7:55:20:6E:00:D7:3A:D3:70:40:F5:49:91:20:90:60
X509v3 Authority Key Identifier:
keyid:70:8F:22:BC:D7:55:20:6E:00:D7:3A:D3:70:40:F5:49:91:20:90:60
DirName:/CN=TestMoregaRootCA/C=CA/O=TestMorega
serial:00
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
CRL Issuer Cert issued by the root
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 20 (0x14)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=TestMoregaRootCA, C=CA, O=TestMorega
Validity
Not Before: Mar 16 18:31:26 2011 GMT
Not After : Mar 11 18:31:26 2031 GMT
Subject: C=CA, O=TestMorega, CN=TestMoregaCRLIssuer
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
...
1c:52:ce:81:2c:50:52:30:43
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
7F:AC:68:90:EE:3C:8B:7B:6D:0E:A0:71:68:BE:57:D0:45:42:E9:C6
X509v3 Authority Key Identifier:
keyid:70:8F:22:BC:D7:55:20:6E:00:D7:3A:D3:70:40:F5:49:91:20:90:60
DirName:/CN=TestMoregaRootCA/C=CA/O=TestMorega
serial:00
X509v3 Key Usage: critical
Digital Signature, CRL Sign
A sample CRL issued by the Indirect CRL Issuer
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: /C=CA/O=TestMorega/CN=TestMoregaCRLIssuer
Last Update: Mar 17 12:56:55 2011 GMT
Next Update: Apr 16 12:56:55 2011 GMT
CRL extensions:
X509v3 Authority Key Identifier:
keyid:7F:AC:68:90:EE:3C:8B:7B:6D:0E:A0:71:68:BE:57:D0:45:42:E9:C6
DirName:/CN=TestMoregaRootCA/C=CA/O=TestMorega
serial:14
X509v3 Issuing Distrubution Point: critical
Full Name:
URI:http://localhost/
Indirect CRL
Authority Information Access:
CA Issuers - URI:http://localhost/crlissuer.cer
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Handling Indirect CRL Issuer
On Thu, Mar 17, 2011, Jeff Saremi wrote: It looks like we need to support indirect CRL Issuers at least for CRL's issued for ourselves. If you don't mind my asking, why do you think you need to do that? I'm curious because so far you're the only person who has needed that functionality and I'm wondering if an alternative solution might be more appropriate. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
