Trying to do this could get real complicated real fast. The first issue is that there are multiple root CAs. I think it's been over a year now since they started using the newest CA, so within another year or so there shouldn't be anyone left with certificates based on the previous root CA. The other problem is that end-user certs aren't signed directly by the root CA like OpenVPN expects. There may be a way to get OpenVPN to trust them if the intermediate CA cert was included. However, OpenVPN doesn't natively support specifying a cert chain. It may still be possible by concatenating the end-user cert with the intermediate cert into the same file, but that will require testing to be sure. That and trying to come up with easy to follow instructions for your clients to accomplish this could be a challenge too. I agree that it's a worthwhile project, but I just wanted to point out the challenges real quick. Hopefully, I'll have more time to help figure it out someday. ;)

On Tue, 15 Mar 2016, Cory (NQ1E) wrote: That's tested, it does work. That's what the VPN server I set up is doing, and the instructions at http://wiki.ampr.org/wiki/AMPRNet_VPN for setting up a client do include steps for concatenating the end-user client cert with the intermediate cert. You can either provide the intermediate certificates in the server-side CA bundle, or the client can have them bundled with the client CA. A more user-friendly approach could be used too, the tQSL application used to have an option to export a PKCS#12 (p12) file, which includes the client's private key, client certificate, and the intermediate cert. OpenVPN can use a PKCS#12 file too instead of a separate key+certs file, but older versions would not pass intermediate certs from the p12 file to the server. I provided openvpn with a patch to add that feature, and it's included in more recent versions of the openvpn client, but I'm not sure if that made it to mainstream Linux distributions yet. - Hessu