Hi, I'm actually testing this with openssl 1.0.1, which explains the behavior. I misunderstood what you where saying about openssl 1.0.1 being "not clever".
Looks like I'll have to wait for openssl 1.0.2 being rolled out to all my clients, or do a hard transition to the new CA, meaning some clients will stop working until installing the new CA certificate. Thank you very much for your help. Regards, Sven. -- PGP Key: https://0x80.io/pub/files/key.asc PGP Key Fingerprint: 2DF2 79CD 48DD 4D38 F0B6 7557 2E68 D557 49AA 1D99 Note: I'll be transitioning away from this key in the near future. On 05/30/2014 12:03 AM, Dave Thompson wrote: >> From: owner-openssl-us...@openssl.org On Behalf Of Sven Reissmann >> Sent: Thursday, May 29, 2014 12:24 > <snip> >> 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). >> > (You didn't really need that, you could just -x509toreq from newroot, > but no harm done as long as the DN is the same and per below it is. > Or you can req -new directly from the key, but that's less convenient.) > >> - 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)" >> > As expected and desired. > >> - 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. >> > If the client trusts only oldroot and server doesn't send bridge, that > should fail. The server isn't providing a chain that reaches something > the client trusts, so the client can't verify the server is authentic. > > If the client trusts only newroot and the server does send bridge, > are you talking about a client using OpenSSL or something else? > OpenSSL client, at least through 1.0.1, doesn't handle that well, > but in my experience other clients (notably browsers and Java) do. > > As I said in part: > <snip> >>> 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. > <snip> > In my simplified description, "not clever" is "dumb". OpenSSL relier (here > client) > through 1.0.1 when it receives a chain that *could* reach a trust anchor > from > the middle (i.e. subCA->newroot) doesn't actually look for that, it looks > only > at the end (i.e. bridge->oldroot?) and when that isn't found it returns > "unverified". > > As indicated I haven't looked whether 1.0.2 will fix this; if it does, I > don't know > when it will be released and how long it will take your systems to be > upgraded > if they even can be (e.g. there is not another dependency on older OpenSSL). > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
signature.asc
Description: OpenPGP digital signature
