Same problem apply for cross-certificates which create multiple paths also.
Imagine the expiring CA (expiring within year or two, not expired already). The organization will create the new one, but want to maintain transition period for the users. So create two cross certificates - the public of oldCA will sign by new CA and vice versa. So resulting structure is: a) public key of newCA is selfsigned, creating root certificate of new tree b) same public key is signed by oldCA with CA:TRUE attribute, creating certificate of intermediate CA authority within old tree End servers with certificate issued by (newCA|intermediate CA) should send following chain: ---------------------------- s: /CN=EndCertificate i: /CN=newCA s: /CN=newCA # This is intermediate CA certificate i: /CN=oldCA ---------------------------- Scenario 1: User is not aware of existence newCA yet (but oldCA is still not expired and trusted by user). Verification: EndCertificate issued by (newCA|intermediate CA) issued by oldCA Conclusion: certificate considered trusted ---------------------------- Scenario 2: User trusting newCA. Verification: EndCertificate issued by (newCA|intermediate CA) which is considered trusted by user, no further steps required Conclusion: certificate considered trusted ---------------------------- Unfortunately, scenario 2 doesn't work with OpenSSL. End-of-chain certificates are verified against trusted store only. So painless transition from one CA to other CA is not possible Dan ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
