X.509 cross certification

blaufish

Hi

Has anyone succeeded in getting X.509 cross certification (similar to e.g. Lets Encrypt, two different roots) to work with OpenVPN ? i.e

server <- Intermediate 1A <- Old_Root
server <- Intermediate 1B <- New_Root

where Intermediate 1A, 1B are generated from the same CSR, and both Old_Root and New_Root generates certificate with the same Subject Key IDentifier (SKID). As such, the server's cert AKID maps to either Intermediate 1A, or Intermediate 1B. This is ideally supposed to allow alternative Certificate Path Construction ( http://www.oasis-pki.org/pdfs/Understanding_Path_construction-DS2.pdf ) so that more than one way to validate the server cert becomes possible.

It would be a nice way to allow deployment of New_Root before Old_Root expires, giving clients plenty of time to upgrade, without needing to set up multiple openvpn listeners.

I've tried many variants of this, unfortunately without demonstrating success. For example, using capath directive with a c_rehash'ed folder,

Server sends an complete certificate chain (verified using Wireshark) always picking the Old_Root path for some reason. Even if that path contains expired intermediates.
Client always picks the Old_Root path, and never picks the New_Path. So the client considers the path expired, even if an unexpired alternative path exists.

TinCanTech

I don't know if this helps:
https://community.openvpn.net/openvpn/wiki/Using_X.509_Certificates

blaufish

Thanks,

TinCanTech wrote I don't know if this helps:
https://community.openvpn.net/openvpn/wiki/Using_X.509_Certificates

Stacked certs on the client doesn't seem to enable alternative paths. It loads fine, but client doesn't try the alternative.

Stacked certs on the server generates an error on alternative paths;

Thu Aug 23 13:06:14 2018 OpenVPN 2.4.6 x86_64-apple-darwin17.5.0 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on May  1 2018
Thu Aug 23 13:06:14 2018 library versions: OpenSSL 1.0.2p  14 Aug 2018, LZO 2.10
...
Thu Aug 23 13:06:17 2018 Cannot load CA certificate file ../ca_test/bundle_ca1_ca2_ca3_ca4.txt (entry 5 did not validate)
Thu Aug 23 13:06:17 2018 Cannot load CA certificate file ../ca_test/bundle_ca1_ca2_ca3_ca4.txt (only 4 of 5 entries were valid X509 names)
Thu Aug 23 13:06:17 2018 Exiting due to fatal error

Not exactly sure what the error message is trying to say, perhaps it got angry because there are two certs with the same subject name.

blaufish

Testing with just openssl s_client / s_server instead yields interesting results,

If openssl s_server -cert_chain chain.txt option is used, the only time alternative path is tried by s_client -verify -verify_return_error, is if only the alternative chain exists in s_client trust store, i.e. -CAfile bundle_alternatives_only.txt
if openssl s_server -cert_chain is not used, alternative paths are tried by clients if they exist in either -CAfile or -CApath.

So a server presenting a certificate chain to client appears to make openssl verify an expired path, fail on it, and not try a trusted alternative path.

blaufish

So,

Got a tip on "Improved Migration" flow ( https://blog.hexonet.net/content/migrating-new-ca-for-openvpn )

Describes using Cross Signing that appears to work well with OpenSSL s_client / s_server and OpenVPN.

Using stacked certs on server, representing the old chain.
Using XS making new clients trust the alternative path only.
Upon old cert expired, any old client cannot connect any more (of course)
Upon old cert expired, new clients ignore this as they evaluate the alternative path.

i.e. one server, but new clients only trusting the alternative chain, old clients only trusting the old chain.

You can apply the flow to more complex certificate paths, the simple server.crt<-OLD-NEW-IM.crt<-(NEW_CA.crt|OLD_CA.crt) is not the only variant, demo'ed it successfully with more layers of intermediates in old path.

Many slight variants, e.g. using capath with all known CAs or stacking old+new CA, produce problems. Avoiding new clients trusting the old intermediate path seems to be the main trick.

oaon

I've been trying to implement this but can only get one or the other chains working, not both together

I have an existing CA that has several months before it expires. I have created a new CA and from it an intermediate CA that I will use to generate server certs. The CSR from the new IM CA has also been signed by the old CA to create a cross signed IM (IMxs).

I've created a server.crt from the new IM so to verify the new CA.

ca = newCA + imCA
cert =  server.crt

a client holding the newCA cert can connect OK.

To verify the new cert to oldCA

ca = oldCA
cert = server.crt + IMxs

A client holding the oldCA cert can connect OK.

When I try to merge the two configs so that clients from either the oldCA or the newCA can connect things come unstuck. Depending on how I bolt things together one or the other (sometimes both) clients fall to connect because they can't verify the server cert due to chain issues.

Does anyone have any more details on how to get this working ?

cheers