Re: Root CA signing an intermediate CA - problems solved
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
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
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 solved
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]
