> From: owner-openssl-us...@openssl.org On Behalf Of Eisenacher, Patrick
> Sent: Tuesday, May 27, 2014 12:41

> > From: Sven Reissmann
> >
> > What I want to achieve is having a new rootCA, which replaces an
> > oldRootCA, which I am using until now.
> >
> > So far the trust chain is: oldRoot -> oldServerCert.
> >
> > What I thought should be possible is building this trust chain:
> > oldRoot -> newRoot -> newSubCA -> newServerCert
> >
> > As Users are trusting oldRoot, changing the oldServerCert to
> > newServerCert is no problem. After some time, users would move trust to
> > newRoot and I can "disable" oldRoot.
> >
> > This doesn't seem possible, if I understand your answers correct.
> >
> > Is there another/better/default way of smoothly changing a trust anchor?
> > I.e. by cross-signing the newRoot by itself and the oldRoot?
> 
> Just add the new root-CA certificate to all relevant truststores. Afterwards 
> you
> can start issueing certificates that are trusted by all parties with updated
> truststores.
> 
If you can get (all) the clients to update, yes. Sometimes that's hard.
Sometimes it's hard even *locating* the clients, especially programs.

You shouldn't cross-sign the new root itself, then it isn't a true root
and (more importantly) won't consistently be accepted as an anchor.

What you can do, and in my experience real public CAs actually do, is:

- create new root key, and new (selfsigned) root cert for it.

- also create a 'bridge' cert for the new root key, and the new root DN if 
different (which it usually is, e.g. Joe's Clam, Oyster and Cert Emporium Gen3 
supercedes Joe's Clam and Cert Shack Gen2), (cross)signed by the old root
(thus with issuer and AKI if present identifying oldroot, but SKI same as 
newroot).

- issue the subCA cert(s) with AKI keyid for the new root key or omitted, and
issuer matching both newroot and bridge, but NOT using AKI issuer&serial 

- have server(s) handshake send subCA and bridge certs, at least for a period 
of time. 
A stale client has only oldroot will chain bridge to oldroot and succeed as 
long as 
oldroot doesn't expire. A clever fresh client has newroot abd will chain subCA 
to 
newroot, ignoring bridge -- while a dumb client will ignore available newroot 
and 
insist on chaining bridge to oldroot. Every time I've looked (not 
systematically) 
major browsers and Java are clever, but OpenSSL (client/relier) through 1.0.1 
is not. 
I know 1.0.2 will change verification but don't know about this particular 
point.



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to