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

[Josh C. <jos...@us...>]

The short summary answer is: don't use multiple CRLs as it compromises
security.  I've discussed each piece a bit more inline, and kept the
really detailed explanations & examples to the footnotes below if you
want that much information.

Karl O. Pinc wrote:
> Hi,
>
> I'm using easy-rsa 2.0 and thinking ahead to what will
> happen when my root CA expires.  I can generate another
> root CA and start all over with an entire fresh
> PKI/easy-rsa directory.   Because --ca file can contain multiple
> certificates in pem format, appended to one another,
> I can use both the old and new root certificates
> during a transition period before the old root cert
> expires.
>   

This is fine, and especially for clients this is an ideal way to prepare
for a CA transition.  Once you've rolled over to the new CA your next
release could omit the old CA certificate.

> It's kind of nice to think of starting over with
> a new PKI, and retiring all the old cruft after
> everyone's using the new root CA cert.
>   

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.)  Not that you can't use a shorter time if required,
but short of CA key compromise there shouldn't really be a need to
rotate CA certs frequently.

> 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?  (I assume that the
> crl is signed by the root ca.)
>   

Correct.  Further, OpenVPN will ignore a CRL that is signed by a
different issuer than the cert being tested (a message will be printed
in the log, but otherwise this happens without note.)

> 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.
> Regardless, it seemed safest to ask here about
> the appropriate procedures to follow when (or some
> time before!) the root CA cert expires.
>
> Thanks.

Short answer: do *NOT* do this as it is a huge security problem. 
Instead, use only 1 CRL at a time that has been generated your live PKI
CA.  Also, if you are expecting to use --crl-verify on clients, read [1]
below.

Long answer: See [2]

[1]
Difficulties in maintaining a client-side CRL:

I assume your original goal was to provide a potentially numerous client
pool with an "interim" CRL list; 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.  The problem here is
that you need a mechanism for the client to periodically update the CRL,
otherwise there is no way to know if the server's cert has actually be
revoked without the client knowing (due to an out-of-date CRL.)  Not
updating the CRL pretty much defeats the purpose of having one in the
first place.

At the very least this update process should happen before the 'Next
Update' field of the CRL, and for the truly security-paranoid it might
need to happen before every connection.  This would require a fairly
involved process to download a new CRL, verify it as legit, and insure
that a MITM attack didn't just feed you a previously valid CRL that
omits a new revoked certificate an attacker is trying to use (perhaps by
downloading the CRL over a TLS or otherwise secure channel.)


[2]
Why not to use multiple CRLs:

This won't do what you expect, and in fact could pose a problem by
allowing revoked certificates to connect.  I tested using OpenVPN
2.1_rc15 & openssl 0.9.8j by creating 2 PKI environments (ca1 & ca2)
each issuing a server and client cert and a signed CRL with no revoked
certs for each CA.  If you have a file containing multiple CRLs, only
the first is read (this is probably an OpenSSL limitation, but I haven't
looked at the sources to confirm.)  Using multiple --crl-verify
directives also doesn't work as only the last one referenced is used.

To demonstrate this, I switched over to using ca2-generated certs for
both client & server, and then revoked the client cert and updated the
concatenated CRL list with crl_ca1 above crl_ca2.  The client cert
signed by ca2 (that was revoked and marked as such in the 2nd CRL) was
allowed to connect with nothing more than a message in the log stating
that the CRL wasn't signed by the same issuer (referring to crl_ca1.) 
If crl_ca2 appears first, or is the only CRL referenced, the client is
denied access due to a failed CRL check, as expected.

This same problem exists in reverse if crl_ca2 appears first by allowing
all rejected certs appearing in crl_ca1 to connect, which also isn't an
acceptable solution if any certs have been marked revoked and are
otherwise still valid.

-- 
Josh