Re: Root CA signing an intermediate CA - problems solved

2001-09-24 Thread Dr S N Henson

Louis LeBlanc wrote:
 
 
 Maybe OpenSSL does it this way when it encounters a cert without a
 pathlen specified, but as I mentioned in an earlier message on this
 thread, Netscape (4.76?) for Linux (running on FreeBSD) seems to
 have a problem.  Adding the pathlen was the final trick that made it
 work.  Without the pathlen, I got
 
 Certificate path length constraint is invalid.
 
 In a Netscape popup.
 

Well if the certificate is correctly encoded and pathlen is absent then
it should interpret it as unlimited. This is specified in a number of
places including RFC2459. If Netscape is doing otherwise then its a bug.

I haven't seen that popup you mention before. If this standard Netscape
4.76 or PSM? I'd like to reproduce it and report it at some point.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: Root CA signing an intermediate CA - problems solved

2001-09-24 Thread Louis LeBlanc

On 09/24/01 01:38 PM, Dr S N Henson sat at the `puter and typed:
 Louis LeBlanc wrote:
  
  
  Maybe OpenSSL does it this way when it encounters a cert without a
  pathlen specified, but as I mentioned in an earlier message on this
  thread, Netscape (4.76?) for Linux (running on FreeBSD) seems to
  have a problem.  Adding the pathlen was the final trick that made it
  work.  Without the pathlen, I got
  
  Certificate path length constraint is invalid.
  
  In a Netscape popup.
  
 
 Well if the certificate is correctly encoded and pathlen is absent then
 it should interpret it as unlimited. This is specified in a number of
 places including RFC2459. If Netscape is doing otherwise then its a bug.
 
 I haven't seen that popup you mention before. If this standard Netscape
 4.76 or PSM? I'd like to reproduce it and report it at some point.

Uh, my bad.  Actually, I am using Netscape Communicator 4.77.   Not a
big difference, but I know accuracy is important.  I am using the
Linux release on FreeBSD (Linux compat is installed).

When I checked my original root cert, this is what I saw:
# openssl x509 -in ca.crt -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=US, ST=Massachusetts, L=Woburn, O=Mirror Image
Internet, OU=En
gineering, CN=Louis [EMAIL PROTECTED]
Validity
Not Before: Oct  2 22:23:29 2000 GMT
Not After : Feb 18 22:23:29 2028 GMT
Subject: C=US, ST=Massachusetts, L=Woburn, O=Mirror Image
Internet, OU=E
ngineering, CN=Louis [EMAIL PROTECTED]
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:ac:46:35:27:20:15:fd:6d:a8:ce:bd:23:dd:77:
e5:18:06:3e:87:0c:2f:b7:b9:f5:fb:5e:f8:76:1e:
4c:cc:2a:5a:a2:31:c9:65:eb:73:09:ae:56:43:68:
9c:08:7f:d7:9e:cd:4f:8c:3f:24:be:2d:94:a3:42:
25:e7:6d:64:48:e1:ad:f5:88:9c:45:dc:f4:37:c7:
a9:c8:f9:56:6e:32:6a:d0:10:cc:a9:1e:12:b6:11:
ca:96:6e:1c:eb:61:b9:db:af:f5:90:5d:10:3f:11:
4f:a5:05:2b:69:e3:cf:bb:7d:8c:61:1e:34:8d:ab:
e9:4d:6f:9c:38:97:58:7f:2d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name: 
email:[EMAIL PROTECTED]
X509v3 Basic Constraints: 
CA:TRUE, pathlen:0
Netscape Comment: 
mod_ssl generated custom CA certificate
Netscape Cert Type: 
SSL CA
Signature Algorithm: md5WithRSAEncryption
55:ed:b6:ae:d6:40:79:68:ab:8f:13:f9:cc:8c:bb:30:64:02:
15:11:45:09:dd:15:d6:9f:e8:84:a7:d4:9a:a8:09:27:a5:70:
6f:72:73:a0:36:ba:9b:ca:77:77:65:29:96:2a:86:44:f3:2f:
34:1b:67:2a:25:fe:c8:43:ea:37:0b:61:d9:f7:b3:35:71:f7:
80:fd:24:17:2c:d7:24:3d:c7:d0:da:34:6f:d8:24:cc:e3:d4:
9d:02:4c:3c:18:22:7b:8c:c8:44:ef:af:33:73:7b:cb:3e:af:
41:72:09:d9:08:1c:3b:d4:25:92:f6:5b:23:a6:f7:78:8c:57:
ce:a0

Notice the X509v3 Basic Constraints.  Quoting from openssl.txt:


Basic constraints is a multi-valued extension that supports a CA and
an optional pathlen option. The CA option takes the values true and
false and pathlen takes an integer. Note if the CA option is false the
pathlen option should be omitted.

The pathlen parameter indicates the maximum number of CAs that can
appear below this one in a chain. So if you have a CA with a pathlen of
zero it can only be used to sign end user certificates and not further
CAs. This all assumes that the software correctly interprets this
extension of course.


So according to this, it is behaving exactly as documented.  Doesn't
seem like a bug to me, just a bit obscure.

I didn't see any description of expected behavior with CA:TRUE and the
pathlen constraint ommitted.  Maybe this is what you expected?  If so,
the reason I had trouble is that pathlen is not ommitted from a self
signed cert by default.  The above X509 description was a default
selfsigned cert.  I had to change the section in openssl.cnf to set it
higher.

I would be interested in knowing what behavior is expected/correct for
the CA:TRUE/no pathlen situation, though.  Seems to me as a matter of
security, you'd want to default that to 0, not infinite.

Thanks a bunch.
Lou
-- 
Louis LeBlanc   [EMAIL PROTECTED]
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
http://acadia.ne.mediaone.net ԿԬ

File cabinet:
  A four drawer, manually activated trash compactor.

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL 

Re: Root CA signing an intermediate CA - problems solved

2001-09-24 Thread Louis LeBlanc

On 09/24/01 01:38 PM, Dr S N Henson sat at the `puter and typed:
 Well if the certificate is correctly encoded and pathlen is absent then
 it should interpret it as unlimited. This is specified in a number of
 places including RFC2459. If Netscape is doing otherwise then its a bug.
 
 I haven't seen that popup you mention before. If this standard Netscape
 4.76 or PSM? I'd like to reproduce it and report it at some point.

Ok, after a quick test, it appears that leaving the pathlen constraint
out altogether will allow intermediate CAs in the chain (I only tested
one so far).  My problem arose because the *default* in the
distributed openssl.cnf file specifies the pathlen as 0, meaning you
can only sign server or user certs, not intermediate CAs.

To be honest, it could be considered (as I mentioned in my previous
post) to be somewhat of a security hole.  Of course the signer should
be deciding to sign a server cert or a CA explicitly, and should test
it afterward, but there is an opening for some human error to be
exploited at some point.  Pretty thin, I know, but it should be
considered.

Looking at the root certs in ca-bundle.crt, distributed with mod_ssl,
the following root CAs do define a pathlen:

American Express Global Certificate Authority
Deutsche Telekom AG
GTE Corporation

All of them define it to be 5.

Interesting.

Regards
Lou
-- 
Louis LeBlanc   [EMAIL PROTECTED]
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
http://acadia.ne.mediaone.net ԿԬ

Any sufficiently advanced technology is indistinguishable from magic.
-- Arthur C. Clarke

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: Root CA signing an intermediate CA - problems!

2001-09-21 Thread Dr S N Henson

Louis LeBlanc wrote:
 
 
 I am including the x509 output of my intermediate below.  I notice
 that the CA constraint is false.  Does this have anything to do with
 the problem?  I am guessing it does, but how do I fix this?  I have
 been all over the online docs, so I am fairly certain that I am just
 not seeing what's in front of me, or my antennae are just not picking
 up the right stations :)
 

This is indeed a problem. With CA:FALSE the certificate is not a valid
CA certificate and will be rejected by any reasonable software. By
default OpenSSL will sign a certificate request using end user
extensions. You can override this using the command line option
-extensions to either 'ca' or 'x509' so if you include -extensions
v3_ca it should work. You can also use the -signCA option to the CA.pl
script in more recent versions of OpenSSL.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: Root CA signing an intermediate CA - problems!

2001-09-21 Thread Louis LeBlanc

On 09/21/01 12:53 PM, Dr S N Henson sat at the `puter and typed:
 Louis LeBlanc wrote:
  
  
  I am including the x509 output of my intermediate below.  I notice
  that the CA constraint is false.  Does this have anything to do with
  the problem?  I am guessing it does, but how do I fix this?  I have
  been all over the online docs, so I am fairly certain that I am just
  not seeing what's in front of me, or my antennae are just not picking
  up the right stations :)
  
 
 This is indeed a problem. With CA:FALSE the certificate is not a valid
 CA certificate and will be rejected by any reasonable software. By
 default OpenSSL will sign a certificate request using end user
 extensions. You can override this using the command line option
 -extensions to either 'ca' or 'x509' so if you include -extensions
 v3_ca it should work. You can also use the -signCA option to the CA.pl
 script in more recent versions of OpenSSL.
 

So will this also result in setting the pathlen?  I noticed on a self
signed cert, CA is true, and there is also a pathlen=0 (or something
to that effect).  I managed to get over the CA:True problem, and even
copied the appropriate extensions, but now, a server cert signed by an
intermediate CA causes netscape to pop up a warning that the
'Certificate path length constraint is invalid.

I am including all Intermediate CA files between the server cert and
the root CA (in that order, but not including the server or root
cert) in a chain.crt file which is pointed to by the
SSLCertificateChain(?) directive in Apache.  If I don't include
directive, I simply get an unrecognized certificate popup, even though
I have installed the root as trusted on my browser.

I'll take a look in openssl.txt for any info on this - this helped me
get over the last hurdle - but if you know offhand, I'd appreciate the
pointer.

Thanks a bunch for the help!

Lou
-- 
Louis LeBlanc   [EMAIL PROTECTED]
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
http://acadia.ne.mediaone.net ԿԬ

All new:
  Parts not interchangeable with previous model.

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Re: Root CA signing an intermediate CA - problems solved

2001-09-21 Thread Louis LeBlanc

Ok, I found the solution, and thought someone else might benefit from
my efforts.

What I am trying to do is create a heirarchy of intermediate CAs with
a single root CA at the top.  I wish to be able to sign server certs,
primarily, and they must be able to create a trusted site that loads
without popup or warning on multiple browsers.  Of course, having the
root CA be trusted is a prerequisite, so I am installing it to the
browser by simply serving it on the site with the proper mime type.

As Dr Henson pointed out, the -extensions v3_ca flag would tell
openssl that the cert was to be considered a CA, and CA:true would be
set in the cert.

However, most default self signed certs also have pathlen:0 set.  This
is a roadblock, and was causing my other issue:
'Certificate path length constraint is invalid.

It's kinda kludgy, but here is what I did:
In my openssl.cnf, I changed the following line in the v3_ca section:
basicConstraints = CA:true
to this:
basicConstraints = CA:true,pathlen:5

which is obviously overkill, but at least I won't have to recreate my
root cert because of this.

the pathlen defines how many intermediate certs can be contained in
the chain between the root and server/user certs.

I then created a subdir in the MYCA directory for each 'first level'
intermediate CA, and copied openssl.cnf into it, decrementing the
pathlen constraint, and pointing the 'dir' directive in CA_default to
the subdir.

Repeat as needed for up to 5 certs deep.

Definitely messy, but I haven't gotten around to fine tuning the whole
thing into a single config that will work with multiple CAs.  When I
get a chance, I'll do it.

For each intermediate CA directory, I set up a script to sign certs
which points to the proper config, so all I have to do is get the csr
into the correct location, and './sign_cert server' will sign
server.csr and output server.crt.

For my purposes, right now, each intermediate subdir is contained
within its 'parent CAs' dir, and each maintains its own serial number
count, index listing, and newcerts store.  They could essentially be
placed on separate machines and continue to be used with minimum
modification.

Like I said, it's messy, but it works for now.

Thanks for the help Dr Henson!

Lou
-- 
Louis LeBlanc   [EMAIL PROTECTED]
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
http://acadia.ne.mediaone.net ԿԬ

Statistics are no substitute for judgement.
-- Henry Clay

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



Root CA signing an intermediate CA - problems!

2001-09-20 Thread Louis LeBlanc

Hey all.  I have a problem I need to solve.

I am testing an SSL client app, and Need to verify that SSL
certificate chains are handled correctly.  So I took my root CA cert,
and used it to sign another cert.  I then used that cert to sign a
cert for my server.

I installed the cert on my server, and installed the intermediate CA
as a chain using the SSLCertificateChainFile directive in the Apache
httpd.conf.  Sounds right to me, and that is what the online Apache
docs say to do.

But . . .
When I try to connect to the server via Netscape on the secure port, I
get the following popup:

The security library has encountered an improperly formatted
DER-encoded message.

Any ideas?

I am including the x509 output of my intermediate below.  I notice
that the CA constraint is false.  Does this have anything to do with
the problem?  I am guessing it does, but how do I fix this?  I have
been all over the online docs, so I am fairly certain that I am just
not seeing what's in front of me, or my antennae are just not picking
up the right stations :)

I appreciate any help.

This is what my intermediate CA looks like:
$ openssl x509 -text -in Int_CA2.crt 
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 32 (0x20)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=US, ST=Massachusetts, L=Woburn, O=Mirror Image Internet, 
OU=Engineering, CN=Louis [EMAIL PROTECTED]
Validity
Not Before: Sep 18 20:25:12 2001 GMT
Not After : Sep 18 20:25:12 2002 GMT
Subject: C=US, ST=Massachusetts, O=Mirror Image, O=Mirror Image Internet, 
OU=Engineering, CN=Louis LeBlanc [EMAIL PROTECTED]
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:e6:57:dd:8c:85:0c:7f:fd:28:cf:0b:af:eb:ba:
26:ef:22:79:df:33:2c:ca:74:eb:1f:0c:15:a3:45:
39:68:b9:fe:e9:f0:3c:9f:a3:f6:94:59:b4:02:b5:
6b:a9:0a:8e:9b:86:f5:1d:7c:13:f7:d2:cc:68:0c:
b0:82:a9:47:90:a3:45:0f:f1:b8:6b:71:18:ff:e5:
6c:26:fd:61:7c:5b:f2:ae:97:ac:e4:5e:45:6f:14:
b4:71:0d:a0:78:97:69:d5:ad:85:2f:29:58:c8:70:
06:79:bd:0f:92:3f:10:3f:f6:f1:1a:a3:94:b1:81:
a3:8f:57:e7:51:24:ae:4f:8d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: 
CA:FALSE
Netscape Comment: 
OpenSSL Generated Certificate
X509v3 Subject Key Identifier: 
61:25:7A:4D:A2:85:95:C2:8D:6D:84:A8:D7:BB:31:7F:4A:E0:0B:04
X509v3 Authority Key Identifier: 
DirName:/C=US/ST=Massachusetts/L=Woburn/O=Mirror Image 
Internet/OU=Engineering/CN=Louis [EMAIL PROTECTED]
serial:00

Signature Algorithm: md5WithRSAEncryption
2a:d5:1a:50:13:be:f4:0b:d3:25:6c:d0:89:43:4a:4c:5e:ac:
7c:41:07:71:30:6d:69:3d:de:b0:36:8d:b4:f0:0a:35:1e:c6:
47:25:80:cb:2b:3c:a6:f6:6b:09:7c:25:62:4a:5d:07:f5:4b:
ed:31:a9:c3:9e:64:b9:d9:f9:23:fa:ad:37:13:7c:8b:cb:27:
fe:a0:0d:35:8c:19:84:e7:a6:4b:6b:ae:df:90:0e:36:84:97:
96:45:b4:42:5c:2e:63:18:74:f6:7a:3c:b7:08:64:68:39:48:
55:ce:96:7a:14:33:7c:21:e8:d7:0f:77:37:2b:55:fa:aa:24:
fe:1d

Thanks
Lou
-- 
Louis LeBlanc   [EMAIL PROTECTED]
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
http://acadia.ne.mediaone.net ԿԬ

QOTD:
  It seems to me that your antenna doesn't bring in too many
  stations anymore.

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]