Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Root CA signing an intermediate CA - problems solved

1,820 views
Skip to first unread message

Louis LeBlanc

unread,
Sep 21, 2001, 3:40:36 PM9/21/01
to
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 leb...@acadia.ne.mediaone.net
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 openss...@openssl.org
Automated List Manager majo...@openssl.org

Averroes

unread,
Sep 21, 2001, 4:37:30 PM9/21/01
to
Hi Louis,

I read your mimi how to for Root CA and Sub-CA?
Sorry for this dummy question, but could you send me
an example of command (openssl ca or openssl x509) you typed
for signing Sub-CA Cert with Root-CA Cert?

in advance many thanks!

Regards

--
# .- ...- . .-. .-. --- . ... .- .-.-.- .- -.-- ... .... .-
# Averroes A. Aysha
# Think Linux, Think Slackware!
# e-fingerprint = 73B7 2559 2968 5094 3B95 5C70 4E85 5F94 6068 1DD8
# http://www.keyserver.net/en/
# .- ...- . .-. .-. --- . ... .- .-.-.- .- -.-- ... .... .-

Louis LeBlanc

unread,
Sep 23, 2001, 1:32:26 AM9/23/01
to
Actually, it is surprisingly simple:
As I pointed out in my earlier message, I used a different config file
with the v3_ca section modified so the basicConstraints line read as
follows:
basicConstraints=CA:TRUE,pathlen:4
This is assuming your root CA has pathlen set at 5. modify by making
each subsequent level one less than the parent level.
And, in the CA_default section, I hardcoded the x509 extensions as
follows:

x509_extensions = v3_ca

Create a perfectly normal cert, using a CN that is appropriate for a
CA (not a dns name).
Then just use this:
openssl ca -config CA.cnf -in csr.pem -out crt.pem

Or as Dr Henson pointed out, leave out the x509 mod in CA.cnf, and use
the following:
openssl ca -config CA.cnf -extensions v3_ca -in csr.pem -out crt.pem

Maybe I'll fine tune this process and write up a better HowTo in the
future (when time permits).

HTH
Lou

On 09/22/01 10:39 PM, Averroes sat at the `puter and typed:


> Hi Louis,
>
> I read your mimi how to for Root CA and Sub-CA?
> Sorry for this dummy question, but could you send me
> an example of command (openssl ca or openssl x509) you typed
> for signing Sub-CA Cert with Root-CA Cert?
>
> in advance many thanks!
>
> Regards
>
> --
> # .- ...- . .-. .-. --- . ... .- .-.-.- .- -.-- ... .... .-
> # Averroes A. Aysha
> # Think Linux, Think Slackware!
> # e-fingerprint = 73B7 2559 2968 5094 3B95 5C70 4E85 5F94 6068 1DD8
> # http://www.keyserver.net/en/
> # .- ...- . .-. .-. --- . ... .- .-.-.- .- -.-- ... .... .-
>

--

Louis LeBlanc leb...@acadia.ne.mediaone.net
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
http://acadia.ne.mediaone.net ԿԬ

Hubbard's Law:
Don't take life too seriously; you won't get out of it alive.

Dr S N Henson

unread,
Sep 23, 2001, 10:54:35 AM9/23/01
to
Louis LeBlanc wrote:
>
>
> 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.
>

That shouldn't be necessary because the absence of a pathlen parameter
should result in the path length being interpreted as unlimited.

I think there was a bug in an older version of OpenSSL that might affect
that but its been fixed in the latest version.

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

Louis LeBlanc

unread,
Sep 24, 2001, 1:04:36 AM9/24/01
to
On 09/23/01 03:53 PM, Dr S N Henson sat at the `puter and typed:

> Louis LeBlanc wrote:
> >
> >
> > 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.
> >
>
> That shouldn't be necessary because the absence of a pathlen parameter
> should result in the path length being interpreted as unlimited.
>
> I think there was a bug in an older version of OpenSSL that might affect
> that but its been fixed in the latest version.

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.

With the pathlen, and with my root CA installed on the browser, you'd
think it was signed by VeriSign. No popups, errors, etc.
My root has pathlen=5, and there are 3 intermediates in the chain
between the server cert and root, and all intermediates are served in
the chain file.

Tomorrow, I'll see if I still have MSIE installed, and try that one.

Regards.
Lou


--
Louis LeBlanc leb...@acadia.ne.mediaone.net
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
http://acadia.ne.mediaone.net ԿԬ

Saliva causes cancer, but only if swallowed in small amounts over a long
period of time.
-- George Carlin

Dr S N Henson

unread,
Sep 24, 2001, 8:59:42 AM9/24/01
to
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: she...@drh-consultancy.demon.co.uk
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: d...@celocom.com PGP key: via homepage.

______________________________________________________________________

Louis LeBlanc

unread,
Sep 24, 2001, 12:55:52 PM9/24/01
to
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 LeBlanc/Email=louis....@mirror-image.com
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 LeBlanc/Email=louis....@mirror-image.com
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:louis....@mirror-image.com
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 leb...@acadia.ne.mediaone.net
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
http://acadia.ne.mediaone.net ԿԬ

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

Louis LeBlanc

unread,
Sep 24, 2001, 4:28:03 PM9/24/01
to
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 leb...@acadia.ne.mediaone.net
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
http://acadia.ne.mediaone.net ԿԬ

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

0 new messages