Re: Intermediate CA extension problems.

2006-05-17 Thread Dr. Stephen Henson
On Tue, May 16, 2006, Phil Dibowitz wrote:

 OpenSSL folks,
 
 I'm having an issue when making an intermediate CA.
 
 As I understand the specs (and please, correct me if I'm wrong), a root
 (i.e. self-signed) CA can be a v1 certificate, but intermediate CAs must:
(a) be v3
(b) have SubjectKeyIdentifier
(c) have AuthorityKeyIdentifier
(d) have BasicKeyConstraints
 


Is there some reason why you want the root CA to be V1? It is better if it is
V3 too.

Depends on the spec you read as to whether those are mandatory. In some specs
SKID/AKID is recommended but not mandatory. In fact it is AKID that is
causing the problem: see below.

BasicConstraints (not BasicKeyConstraints) is mandatory though because that
indicates the intermediate certificte is a valid CA.

 Based on that I have a CA that is self-signed with only
 crlDistributionPoint in it. I'm trying to create an intermediate CA with
 the above extensions in it and I'm having a problem. I have this in my
 config:
 

Well if you have an extension then it can't be a v1 certificate.


[ v3_ca ]
basicConstraints = CA:TRUE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
 
 But when I run:
openssl ca -config openssl.cnf -extensions v3_ca -infiles \
certreqs/sub_ca.csr
 
 I get:
Using configuration from openssl.cnf
Check that the request matches the signature
Signature ok
ERROR: adding extensions in section usr_cert
32587:error:2207707B:X509 V3 routines:V2I_AUTHORITY_KEYID:unable to
get issuer keyid:v3_akey.c:151:
32587:error:2206B080:X509 V3 routines:X509V3_EXT_conf:error in
extension:v3_conf.c:92:name=authorityKeyIdentifier,
value=keyid:always
 
 I have a similar setup using a non-openssl solution, thus I'm fairly
 sure what I want to do is possible, I'm just missing something. Any help
 would be greatly appreciated.
 

Your problem is that you are telling OpenSSL to include the AKID extension by
copying the SKID from the issuing CA. That CA doesn't have an SKID extension
so it gives the error.

Either remove that extension from the config file or include SKID in the root
CA.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


Re: Intermediate CA extension problems.

2006-05-17 Thread Phil Dibowitz
Dr. Stephen Henson wrote:
 Your problem is that you are telling OpenSSL to include the AKID
 extension by
 copying the SKID from the issuing CA. That CA doesn't have an SKID
 extension
 so it gives the error.
 
 Either remove that extension from the config file or include SKID in the
 root
 CA.

So as I mentioned previously, I saw a proprietary solution doing this
(generating an AKID keyID without a parent SKID), even though I realized
it made no sense. So I called them on it. I asked how they were getting
a keyID for AKID when the parent CA had no SKID.

They informed me they're calculating a hash of the public key of the
parent public key for the AKID... in other words - they're generating a
SKID for the parent even though it doesn't have one.

Intuitively, this kinda seems wrong to me, but reading the RFC it seems
to comply. AKID keyId just needs to uniquely identify the parent public
key. I'm curious what your thoughts on this are. Is this a reasonable
thing to do? Are there problems with this? In the case where I have
this, I plan to re-sign the parent to have SKID, but I'll be in this
configuration for a bit before I can do that. Is this AKID bad in any way?

Thanks.
-- 
Phil Dibowitz
P: 310-360-2330 C: 213-923-5115
Unix Admin, Ticketmaster.com



signature.asc
Description: OpenPGP digital signature


Re: Intermediate CA extension problems.

2006-05-17 Thread Dr. Stephen Henson
On Wed, May 17, 2006, Phil Dibowitz wrote:

 Dr. Stephen Henson wrote:
  Your problem is that you are telling OpenSSL to include the AKID
  extension by
  copying the SKID from the issuing CA. That CA doesn't have an SKID
  extension
  so it gives the error.
  
  Either remove that extension from the config file or include SKID in the
  root
  CA.
 
 So as I mentioned previously, I saw a proprietary solution doing this
 (generating an AKID keyID without a parent SKID), even though I realized
 it made no sense. So I called them on it. I asked how they were getting
 a keyID for AKID when the parent CA had no SKID.
 
 They informed me they're calculating a hash of the public key of the
 parent public key for the AKID... in other words - they're generating a
 SKID for the parent even though it doesn't have one.
 
 Intuitively, this kinda seems wrong to me, but reading the RFC it seems
 to comply. AKID keyId just needs to uniquely identify the parent public
 key. I'm curious what your thoughts on this are. Is this a reasonable
 thing to do? Are there problems with this? In the case where I have
 this, I plan to re-sign the parent to have SKID, but I'll be in this
 configuration for a bit before I can do that. Is this AKID bad in any way?
 

Well AKID is supposed to be a hint to the authority certificate by matching
its SKID. If the authority doesn't have an SKID then its a bit misleading.

That wont matter to OpenSSL but other software might decide because the
authority doesn't have a matching SKID then it isn't the real signer.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


Intermediate CA extension problems.

2006-05-16 Thread Phil Dibowitz
OpenSSL folks,

I'm having an issue when making an intermediate CA.

As I understand the specs (and please, correct me if I'm wrong), a root
(i.e. self-signed) CA can be a v1 certificate, but intermediate CAs must:
   (a) be v3
   (b) have SubjectKeyIdentifier
   (c) have AuthorityKeyIdentifier
   (d) have BasicKeyConstraints

Based on that I have a CA that is self-signed with only
crlDistributionPoint in it. I'm trying to create an intermediate CA with
the above extensions in it and I'm having a problem. I have this in my
config:

   [ v3_ca ]
   basicConstraints = CA:TRUE
   subjectKeyIdentifier = hash
   authorityKeyIdentifier = keyid:always

But when I run:
   openssl ca -config openssl.cnf -extensions v3_ca -infiles \
   certreqs/sub_ca.csr

I get:
   Using configuration from openssl.cnf
   Check that the request matches the signature
   Signature ok
   ERROR: adding extensions in section usr_cert
   32587:error:2207707B:X509 V3 routines:V2I_AUTHORITY_KEYID:unable to
   get issuer keyid:v3_akey.c:151:
   32587:error:2206B080:X509 V3 routines:X509V3_EXT_conf:error in
   extension:v3_conf.c:92:name=authorityKeyIdentifier,
   value=keyid:always

I have a similar setup using a non-openssl solution, thus I'm fairly
sure what I want to do is possible, I'm just missing something. Any help
would be greatly appreciated.

Thanks,
-- 
Phil Dibowitz
P: 310-360-2330 C: 213-923-5115
Unix Admin, Ticketmaster.com



signature.asc
Description: OpenPGP digital signature