| Summary: | OpenVPN: Are our certificates ever RFC3280 compliant? | ||
|---|---|---|---|
| Product: | IPFire | Reporter: | Michael Tremer <michael.tremer> |
| Component: | --- | Assignee: | Michael Tremer <michael.tremer> |
| Status: | NEW --- | QA Contact: | |
| Severity: | - Unknown - | ||
| Priority: | - Unknown - | CC: | adolf.belka, daniel.weismueller, stefan.schantl, ummeegge |
| Version: | 2 | ||
| Hardware: | unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | |||
| Bug Blocks: | 13633 | ||
| Attachments: | ovpn.cnf openssl file from CU184 system | ||
*** Bug 12565 has been marked as a duplicate of this bug. *** Adolf reported that he has never seen this message. Current working assumption: We don't seem to update the OpenSSL configuration file for OpenVPN which results in the old-style certificates being generated again. Needs verification. It looks like a change was made to ovpn.cnf in CU115 to update it for extended key usage etc. in Oct 2017 https://patchwork.ipfire.org/project/ipfire/patch/1507295688-7140-1-git-send-email-erik.kapfer@ipfire.org/ The status of that patchwork entry shows DROPPED but in the communications it says that it was merged. As far as I can see there is then a following entry from you which does ship that ovpn.cnf with CU115. https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=ebf697a097f38c11a603e22f7f742e24bba601a2 However in CU120 (Feb 2018) Erik then submits a patch to ship ovpn.cnf saying that it was not delivered in CU115 https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=39d11d265e4f1a41994d0adf85498f54c63ba7ab It looks like something did not go right with the shipping of the ovpn.cnf somewhere. It could be that the above hiccups end up giving the situation that the ovpn.cnf is maybe not correctly updated. Created attachment 1519 [details]
ovpn.cnf openssl file from CU184 system
This is the ovpn.cnf file from my production CU184 system. This system was freshly installed mid 2023 so the ovpn.cnf should be a recent version, only missing the changes I have made to it for the CU185 release.
@Michael you could diff that with your version that gives the error message and see if the differences match in with the patch that @Erik submitted in 2017.
Thinking about it anyone updating to CU185 when it is released should end up getting the corrected ovpn.cnf file even if they did not get it back in CU115 or CU120.
(In reply to Adolf Belka from comment #4) > Thinking about it anyone updating to CU185 when it is released should end up > getting the corrected ovpn.cnf file even if they did not get it back in > CU115 or CU120. Are you sure the file is in the updater this time? > https://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=commitdiff;h=b5bddbae30ded06944576b3275564cd6cfcc2022 As far as I can see this is not *really* a problem. It is a little bit ugly because we cannot use "remote-cert-tls server" which simply checks if the certificate has been issued for a server instead of someone abusing another client certificate. Formerly we used an option called "ns-cert-type server". That has been removed in OpenVPN 2.5 and so I removed it from our generated configuration files as it causes an ugly warning messages when the certificates actually work just fine. This was part of cleaning up the client configuration file and remove all options that we don't need: > https://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=commitdiff;h=110b98dfe7d43a8190dff54702947be088dd8000 (In reply to Michael Tremer from comment #5) > (In reply to Adolf Belka from comment #4) > > Thinking about it anyone updating to CU185 when it is released should end up > > getting the corrected ovpn.cnf file even if they did not get it back in > > CU115 or CU120. > > Are you sure the file is in the updater this time? > I believe so. If it was not included then the Core Update 185 Testing would still have resulted in a root/host certificate creation that failed to create the root certificate. In my testing of CU185 Testing after the ovpn.cnf change ended up in the nightly build I was able to successfully create the x509 root/host certificate set. I believe that should mean that the updater will work correctly when CU185 is given its full release. (In reply to Adolf Belka from comment #6) > (In reply to Michael Tremer from comment #5) > > (In reply to Adolf Belka from comment #4) > > > Thinking about it anyone updating to CU185 when it is released should end up > > > getting the corrected ovpn.cnf file even if they did not get it back in > > > CU115 or CU120. > > > > Are you sure the file is in the updater this time? > > > > I believe so. If it was not included then the Core Update 185 Testing would > still have resulted in a root/host certificate creation that failed to > create the root certificate. Thank you for double-checking. I just wanted to be sure that we actually ship it in the updater and there is no exclude rule that would filter it out. > I believe that should mean that the updater will work correctly when CU185 > is given its full release. Yes, I believe this is okay then. We should move system configuration files that we manage out of /var/ipfire so that the exclude rules become easier to manage. This might also become relevant for the planned snapshot feature. (In reply to Michael Tremer from comment #7) > (In reply to Adolf Belka from comment #6) > > (In reply to Michael Tremer from comment #5) > > > (In reply to Adolf Belka from comment #4) > > > > Thinking about it anyone updating to CU185 when it is released should end up > > > > getting the corrected ovpn.cnf file even if they did not get it back in > > > > CU115 or CU120. > > > > > > Are you sure the file is in the updater this time? > > > > > > > I believe so. If it was not included then the Core Update 185 Testing would > > still have resulted in a root/host certificate creation that failed to > > create the root certificate. > > Thank you for double-checking. I just wanted to be sure that we actually > ship it in the updater and there is no exclude rule that would filter it out. > > > I believe that should mean that the updater will work correctly when CU185 > > is given its full release. > > Yes, I believe this is okay then. We should move system configuration files > that we manage out of /var/ipfire so that the exclude rules become easier to > manage. This might also become relevant for the planned snapshot feature. I am sorry but it looks like it did not work correctly in CU185 full release. I don't understand this as I tested it out with CU185 Testing and the ovpn.cnf was updated and it worked but now with CU185 full release it has not worked. The ovpn.cnf was not updated during the upgrade. Checking the exclude file it has an entry of /var/ipfire/ovpn does this mean that all files and all directories under ovpn are never updated. If so that would explain why it was not updated with the full release but not why it worked with CU185 Testing on my system. I just checked back to CU115 when the original change to ovpn.cnf was made. The line /var/ipfire/ovpn was in there back then as well and has never been changed as far as I can see. If that line does prevent anything under the ovpn directory being updated then none of the historic changes to ovpn.cnf has ever been applied in a Core Update, only from a fresh install. The only way to update it would be via the update.sh script by editing the file in situ. |
> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/ovpnmain.cgi;h=c92d0237d2d1372656d0d6a71d9b9ee5bc663c9a;hb=HEAD#l246 Here we check whether certificates are compliant with RFC3280. However, I believe that even newly generated certificates are not compliant which means that we will always see the message here. We need to investigate whether that is correct and if so either migrate the issues certificate or at least generate correct ones from now on. I will remove the message in the meantime as it annoys me quite a lot.