Bug #10649
closed
OpenVPN Cllient Export Wizard Using Wrong Root CA Certificate
0%
Description
This occurs using pfSense 2.4.5-RELEASE (arm) on an SG-3100. OpenVPN CE Wizard v1.4.23.
I had two Root CAs in pfSense's Certificate Manager. #1 is a chained, self-signed Root and Intermediate certificate pair (my Root CA plus a CA key signed with my Root CA). #2 is a pfSense-generated certificate. The computer I am using is Windows 10 64-bit. CA #1 (and the Root CA used to sign it) are both installed in Windows CertMgr under Trusted Root Certification Authorities.
When I set up OpenVPN, I used CA #2 to sign an pfSense-generated OpenVPN server certificate (CERT #1), while I spent time understanding how to use OpenSSL 1.1.1. It took me some time to adapt my scripts to put the needed attributes into the certificate from CA #1.
Yesterday I finished my research and imported the new certificate signed by CA #1 (along with its private key); note that the certificate contains the complete CA chain (root and intermediate) along with the server certificate. Let's call this CERT #2. After importing, I edited the Server config to switch to CA #1 as the Peer Certificate Authority, and the newly-signed certificate (by CA #1)
All the attributes were correct, but OpenVPN was giving me an error that the Root CA was unknown. I opened the OVPN bundle file with Notepad ++ (on Windows) and was able to determine that the Intermediate CA was from #2, but the exported Root CA was from #1.
I manually copied the correct encoded CERT data from Root CA #1's certificate file, pasted it into the OVPN file and re-exported that to iOS. Now everything works fine.
I have two different VPN ports opened on my router, and after the first one worked I reconfigured and exported the second. Same Root CA certificate problem; also fixed with manual copy and paste.
It seems that the OpenVPN Export package, for some reason, grabs the wrong Root CA on a chained CA set, at least when there is a pfSense self-signed CA plus another Root CA generated by OpenSSL outside of pfSense.
Note in my initial paragraph I said I had two root CAs installed in pfSense. I have since deleted CA #1 and its certificates, as I do not need them (and I am hopeful that whenever I re-export things, it will put the correct CA certs in place since there is only one saved in pfSense now).
Updated by Dennis Adler over 4 years ago
Note: I posted this initially on the Netgate forums. Several views but no feedback. Perhaps not many people set up a full CA to manage their certificates, or if they do they did not start with the pfSense-generated CA/Cert set and still have them active when switching to their root CA-set and exporting the OpenVPN Client config...?
Updated by Jim Pingle over 4 years ago
- Status changed from New to Not a Bug
Either your CA/Cert subjects are not unique and it formed an incorrect internal association on import, or you imported things incorrectly:
note that the certificate contains the complete CA chain (root and intermediate) along with the server certificate
Don't do this. Import each item separately.
Highly unlikely to be a bug.
Updated by Dennis Adler over 4 years ago
Either your CA/Cert subjects are not unique and it formed an incorrect internal association on import, or you imported things incorrectly:
If the CA/Cert subject were not unique, then OpenSSL would complain. And how would improperly chained certs work properly for pfSense HTTPS Web GUI access and OpenVPN from Windows and iOS devices? Here are the CA/Cert Subjects for all 3 certs for your review (I replaced my domain name with X's, but the net effect is the same):
CA Root Subject: E = admin@XXX.XXX, CN = XXX Root Authorithy, O = XXX.XXX, L = Seattle, S = WA, C = US
Yes I know I misspelled Authority, but I'm not redoing my root CA cert for that. The certification path is XXX Root Authorithy since it is self-signed.
Intermediate CA Subject: E = admin@XXX.XXX, CN = XXX Intermediate Signing Authority #2, O = XXX.XXX, S = WA, C = US
The certification path is:
XXX Root Authorithy
XXX Intermediate Signing Authority #2
The Cert (paired with the a private key) used for HTTPS and OpenVPN on my pfSense box has the following Subject: E = admin@XXX.XXX, . The issuer is listed as the Subject entry from
CN = sg-router.XXXX.me, O = XXX.XXX, S = WA, C = USXXX Intermediate Signing Authority #2 (my Intermediate CA). The certification path is:
XXX Root Authorithy
XXX Intermediate Signing Authority #2
If there flaws in this chain, please let me know what I need to fix. I've been using these two CA certs for more than 3 years without problems. And the problem I'm seeing isn't with use of the CA certs, but with how the OpenVPN wizard exports them.
note that the certificate contains the complete CA chain (root and intermediate) along with the server certificate
Don't do this. Import each item separately.
Then why does the pfSense documentation say that is exactly how to do it, see: [[https://docs.netgate.com/pfsense/en/latest/book/certificates/certificate-authority-management.html]]
Here is the relevant text from the doc page:
Importing a Chained or Nested Certificate Authority
If the CA has been signed by an intermediary and not directly by a root CA, it may be necessary to import both the root and the intermediate CA together in one entry, such as:
-----BEGIN CERTIFICATE-----
[Subordinate/Intermediate CA certificate text]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Root CA certificate text]
-----END CERTIFICATE-----
Highly unlikely to be a bug.
Gertjan on the forum said he's willing to try a repro case, and I've posted details of my signing certs there too.
Updated by Jim Pingle over 4 years ago
That particular document is outdated, the Cert Manager supports forming chains on its own now. I have a setup with intermediate certs and it works perfectly for me internally and in the export package (except for CRLs, but that's already got its own separate issue).
Updated by Dennis Adler over 4 years ago
Jim Pingle wrote:
That particular document is outdated, the Cert Manager supports forming chains on its own now. I have a setup with intermediate certs and it works perfectly for me internally and in the export package (except for CRLs, but that's already got its own separate issue).
Did your export package case have both your chained CA certificates installed at the same time as a pfSense-generated CA (with a signed VPN certificate) that had been used previously? That may be a key part of the repro case.
As for the documentation being out of date: The advice on chained certificates is unchanged in both the March 26, 2020 (see page 145) and the June 09, 2020 (also on page 145) PDF versions of The pfSense Book (the June version is listed by Netgate as the newest version). How are users supposed to know that this is no longer required?? And just because it isn't required, does that mean it has stopped working for everyone who followed those directions? That is, are you saying everyone who has installed properly-signed certificates from a properly-chained CA certificate now needs to go back and install each CA certificate individually, else OpenVPN Export won't work?? If so, that is a fairly poor end-user experience, and should not only be documented in the manual, but also in the release notes where for the version where that was changed.
On the other hand, if the previously documented method for importing chained CA certificates should still work (which I hope is the case), then this is indeed a bug; one that I hope is fixed (along with the documentation). Again, this may only happen with the particular CA configuration on pfSense that I reported.
And why is the pfSense book 100% wrong about this (i.e. so out of date)? Why does it not warn people they need to change this, if the behavior is no longer supported?