Re: [Openvpn-users] --crl-verify and transitioning from an expiring CA cert

[Karl O. P. <ko...@me...>]

Thanks for the response.  I'm kind of talking my way through
the issues I see as I go.  I hope you don't mind.

On 04/06/2009 01:09:28 AM, Josh Cepek wrote:

> Karl O. Pinc wrote:
> > I'm using easy-rsa 2.0 and thinking ahead to what will
> > happen when my root CA expires.

> Normally its a good idea to put the root CA expiration far enough into
> the future that this won't an issue for a good long while (10+ years
> is
> frequently used.)

Someday the root CA ert is going to expire, and what happens then?
Nobody wants a "flag day" where everything has to switch
over to the new PKI at once.

What I was thinking
when I wrote the original message was that during a
transition period clients would be deployed
using only the new PKI and the
servers would have the 2 root CA certs in their
--ca file, so would accept connections from both
old and new clients.  But this means having
more than one CRL on the servers, one for each
PKI.

(FWIW, My approach towards things that expire is to have them
expire often enough that staff has experience and
expiration is not a unique event.  When nobody has
any experience with a situation mistakes are made.
Naturally update frequency must be tempered by a
desire to minimize unnecessary work.)

> > What I'm wondering about is what to do with the
> > certificate revocation list.  The docs on --crl-verify
> > do _not_ say that the file can contain multiple crls
> > in pem format.  So the question is how to continue
> > to revoke certificates associated with the old root
> > CA cert, while still being able to revoke certificates
> > associated with the new CA cert?

> > My guess, based on the openssl verify docs, is that
> > it might be possible to have the --crl-verify
> > file consist of multiple appended crls in pem format.

> Short answer: do *NOT* do this as it is a huge security problem.

Ok.


> .  Also, if you are expecting to use --crl-verify on clients, read
> [1]
> below.

I'm not.  I'm only interested in CRLs on the server.

> ... if this was just to maintain a CRL
> on
> servers you could roll in the new CRL when you switched CAs and avoid
> the desire to run dual CRLs in the first place.

Correct me if I'm wrong.  The only way to have deployed clients
that work with both the old root CA and the new root CA,
thereby avoiding having to update all the clients when
the new root CA/PKI is activated on the server, is
to have the client certs signed by both the old and new root CA
certs.  This is doable but means stepping outside the bounds of
easy-rsa, at least as I understand it.  (There is build-req
and sign-req, but that means manually schlepping stuff around
and does not address the issue of maintaining 2 CRLs
during the transition and other matters involved
in keeping 2 PKIs going at once.)

It would be nice if easy-rsa supported a transition to a new
root CA cert/PKI.  Perhaps it could do this by supporting
multiple "keys" directories: adding and revoking keys
in all "keys" directories, making sure that client
keys in the "old" PKI
are signed by both root CA certs, updating CRLs in both
"keys" directories, etc., until such time as the old PKI
is retired.  (I like the idea of separate directories
because I like the idea of being able to throw old stuff
away.)

If there is already easy-rsa support for transitioning
to a new root CA cert please explain or point me to
where I can RTFM.

Or maybe there's another way.  Maybe it would actually
be simpler to allow more than one --crl-verify file,
or there's some other way entirely.

Thanks for the testing and the help.

Karl <ko...@me...>
Free Software:  "You don't pay back, you pay forward."
                  -- Robert A. Heinlein