How can I create and use the cross signing certificate?
: I'm trying to create an environment with cross-signed CAs, and verify a certificate issued against one of the CAs, all using openssl. The best I got so far is getting openssl into an endless loop while verifying (the loop is terminated at level 100). I've published all of the certs I created. Now, there are a number of assumptions that I'm making, and largely based on this Oasis document to build the model. Here are my assumptions:
There should be 4 certificates, self-signed from authorities #1 and #2, and cross-signed, where authority #1 is signed by authority #2 and vice versa.
There are only 2 actual subjects (DNs) used (the same subject used by an authority for self-signed is what it has signed by the other authority, albeit in a different cert).
All 4 certificates should be part of the end-user trust.
The keys used by the same authority, for both self- and cross- signed certificates should be the same
AKI should not be used (Maybe "shouldn't" is too strong a word, but not using it shouldn't hurt. Because of the same keys rule, it shouldn't matter though)
I tried setting CA:TRUE for cross-signed certs, with the same result.
My understanding of cross signing is that it gives the verification process alternative paths. Considering that I see an openssl loop, it seems to be picking cross-signed certificates every time. So the crux of the question is - what would make the verification process to favour the self-signed certificate over the cross-signed one, considering both have the same subject. Here is a test leaf certificate, I can't make openssl verify to verify it successfully.
[vps@druid]~/ws/EF/pki3$ openssl verify -verbose -CAfile cas.pem cert.pem
cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 2
error 2 at 100 depth lookup:unable to get issuer certificate
OK, this is the best that I came up with so far.
The problem with depth processing, I believe, is just OpenSSL's. It's not good that it can't build proper paths. RFC-5280, Sec 6.1 says: A certificate MUST NOT appear more than once in a prospective certification path. OpenSSL probably violates that. However, I have to say that I don't quite see an explanation in RFC-5280 on how to build paths, except for its Sec 3.2; there are suggestion that paths must end with a single self-signed CA at the end of each chain (that, however, contradicts with statements that verification chain should not have trust anchors, but trust anchors may contain intermediate certs, which makes the post-chain side contain multiple certificates, where OpenSSL ends up with infinite loop). Either way, I don't agree with what OpenSSL is doing.
I also should say that what I was talking about is not just cross signing certificates, but mutually cross signed certificates. The obvious difference is that normal cross-signed don't create such a circular dependency, and is achieved by having a trust anchor from one CA that is signed by another CA (from the perspective of verifier, it's the same case as a trusted intermediary, AFAIU). The way to make it work with OpenSSL, is by not adding cross signed certs into the trust list, but provide them as part of the intermediate certificates produced by the key holder.
If I put all self-signed in trust.pem, all cross-certs in untrust.pem, then verifier works, albeit spews intermediate errors (which makes sense as not all trees build/verify successfully):
Here is with both roots present:
$ openssl verify -verbose -CAfile trust.pem -untrusted nontrust.pem host1/cert.pem
host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1
error 24 at 1 depth lookup:invalid CA certificate
C = US, O = Excelfore, OU = PoC, CN = xl4 CA 2error 24 at 2 depth lookup:invalid CA certificate OK Here is with only one or another root present:
$ openssl verify -verbose -CAfile ca1/ca1.pem -untrusted non trust.pem host1/cert.pem
host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1
error 24 at 1 depth lookup:invalid CA certificate
C = US, O = Excelfore, OU = PoC, CN = xl4 CA 2
error 24 at 2 depth lookup:invalid CA certificateOK
$ openssl verify -verbose -CAfile ca2/ca 2.pem -untrusted non trust.pem host1/cert.pem
host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1
error 24 at 1 depth lookup:invalid CA certificate
OKWhich shows the coolest part of the cross signing that we can nuke a CA, and still have original certs working.
HOWEVER RFC-5246, Sec. 7.4.2 that documents TLS 1.2 says that the server has only one chain to present to the client (and vice versa). If the cross signed certs can not be part of the trust store, then the client has to provide multiple chains in order for the verifying side that there are options. So, yes, it works in theory, but not with SSL (it may work with other verification protocols, I didn't check), at least in OpenSSL implementation of it.