Hi, Dave, thank you very much for your suggestions. This sounds like the solution I'm looking for. I've set up a completely new PKI to test this, but I'm still having one problem.
What I did was: - I generated a newRootCA (new keypair, selfsigned certificate). - I generated another selfsigned certificate (bridgeCert) from the newRootCA's private key. From this cert, I used the -x509toreq option to generate a csr (bridgeCSR). - I took the bridgeCSR and issued a certificate using the oldRootCA. The certificate issued has AKI = oldRootCA and SKI = newRootCA - I generated a CSR for a new subCA and issued a certificate using newRootCA. The AKI of the subCA cert is the same as the SKI of newRootCA and bridgeCert. The AKI does not include any issuer or serial information What I am able to do now is: - As long as I trust oldRoot and my server handshake send subCA and bridge, the trustchain verifies: "Verify return code: 0 (ok)" - As long as I trust newRoot any my server handshake send subCA but NOT bridge, the trustchain verifies: "Verify return code: 0 (ok)" - If I only trust newRoot but send the bridgeCert, I get an error. Also, if I only trust oldRoot and do not send bridge, I get an error. Am I still missing something? Regards, Sven. > 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. -- PGP Key: https://0x80.io/pub/files/key.asc
signature.asc
Description: OpenPGP digital signature
