X.509 cross certification

This forum is for admins who are looking to build or expand their OpenVPN setup.
Forum rules
Please use the [oconf] BB tag for openvpn Configurations. See viewtopic.php?f=30&t=21589 for an example.
Post Reply
blaufish
OpenVpn Newbie
Posts: 4
Joined: Fri Aug 24, 2018 9:34 am

X.509 cross certification

Post by blaufish » Fri Aug 24, 2018 9:52 am

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/Understan ... on-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.

User avatar
TinCanTech
OpenVPN Protagonist
Posts: 5095
Joined: Fri Jun 03, 2016 1:17 pm

Re: X.509 cross certification

Post by TinCanTech » Fri Aug 24, 2018 1:42 pm


blaufish
OpenVpn Newbie
Posts: 4
Joined: Fri Aug 24, 2018 9:34 am

Re: X.509 cross certification

Post by blaufish » Mon Aug 27, 2018 8:51 am

Thanks,
TinCanTech wrote:
Fri Aug 24, 2018 1:42 pm
I don't know if this helps:
https://community.openvpn.net/openvpn/w ... rtificates
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;

Code: Select all

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
OpenVpn Newbie
Posts: 4
Joined: Fri Aug 24, 2018 9:34 am

Re: X.509 cross certification

Post by blaufish » Thu Aug 30, 2018 4:14 pm

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
OpenVpn Newbie
Posts: 4
Joined: Fri Aug 24, 2018 9:34 am

Re: X.509 cross certification

Post by blaufish » Tue Sep 04, 2018 7:41 am

So,

Got a tip on "Improved Migration" flow ( https://blog.hexonet.net/content/migrat ... or-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.

Post Reply