But first I went ahead with update to 153 and wanted to solve this then.
After having update finished + rebooted IPFire, I tried to fix this, but didn’t succeed so far. Stopped the OpenVPN Service and deleted the x.509 certificates. The Client-to-Net configurations were also deleted automatically.
Now I’ve already tried three times to generate new host certificates and keys but it shows every time again the same warning. Tried it with different parameters (DH 4096) but for example DH and key always come up with 2048 Bit.
Anyone with an idea how to proceed or why it can’t generate certificates with DH-Parameter 4096 bit or why repeatedly claiming crypthographic warning? Found only 3 older Threads troubleshooting this OpenVPN problem and none of them with a solution. Google shows 3 more but they point to the old forum, which is no longer available.
Selecting “Remove x509” should do what you are asking for. I did that last July, just after Core Update 147 and upgraded my Diffie-Hellman parameter to 4096 and everything went without a hitch for me.
I would not expect to see what you are experiencing.
My only suggestion in that situation would be to remove the x509 root and host certificates, make a backup and then install 153 from fresh.
Then make the x509 root and host certificates again before restoring the backup to ensure it works as it should with a pristine install of 153.
Then, if that has worked OK, restore from your backup and see if everything is still OK.
Question is about the Diffie-Hellman parameter length. GUI offers 4096 bit. Wiki also states to have the choice 2048, 3072 and 4096. It should be only a question of patience to generate it. But it comes back with 2048, when 4096 was ordered.
So, what happens? Long time nothing. The GUI page shows ‘busy’ and ends up in a timeout after certain time. I’ve waited quite long (1+ h). The system has a HWRNG and the Intel J1900 is usually fast enough to work this out in less than half an hour. After a reload I get what is shown in the second screenshot.
I see, the reason I asked, I was interested in whether the whole process is broken and whether it changes anything if only DH itself is recreated. So you have confirmed that only 2048 is possible, no matter what you try. This is really strange. The normal process should work as Adolf described. But with the backup I’m not sure if you have the same error again afterwards.
At the moment i have no idea whats the next best(maybe better) step. Sorry
thank you also for your evaluation. Finally after some more tries I’m a small step forward. Now it generated a 4096 Bit DH-Parameter (can’t retrace why not 4 times before), but still complains to fail RFC3280.
Due to “Update 123 OpenVPN Host Zertifikat RFC3280 nicht Regelkonform” I could figure out that my ovpn.cnf is somehow outdated. Since the file from my IPFire is from 2016, it’s very likely that it has also not been updated with the meanwhile Core-Updates.
Maybe someone or even @ummeegge could compare a current ovpn.cnf with the one attached or confirm that this sample on git.ipfire.org from Core 123 / Sept 8th 2018 (Link above) is still valid for Core 153?
ovpn.tar (2,4 KB)
Current ovpn.cnf from my IPFire. Pls replace file extension tar with cnf.
I think, an up-to-date ovpn.cnf will cure the problem and will save me to go the long way with a pristine install aso.
I compared your ovpn.cnf with my one and with the one you linked to from Core 123.
I found differences with the usr cert and the server cert. What is missing from yours is the x509 extensions. When reading that I realised that I remember something from some time back about these x509 extensions. They didn’t used to exist but came in and eventually became something that was required. It looks like your .cnf file never got updated for some reason.
I have looked at the ovpn.cnf file from Core 123 and it is the same as the one on my system except that mine does not have the RANDFILE line in it.
Here is the link to the version that is in Core 153. This also does not have the RANDFILE line.
This has nothing to do with the DH-Parameter (small hint comes nevertheless at the end) this problem appears that all existing clients rely on the deprecated “Netscape” cert attribute which uses the ‘–ns-cert-type server’ directive. IPFire´s host certificate (in that way the root certificate too) needs to be regenerated with the new defined key usage extension entries. Here --> OpenVPN '--ns-cert-type' is deprecated - forum.ipfire.org you can find a deeper explanation of this topic.
After creating the new certificates you can execute e.g.
I replaced the ovpn.cnf with the one from git.ipfire.org. The RFC3280 warning is gone now.
Generating the certificates with DH 4096 Bit takes approximately 40 minutes. Thats ok for me. I can not swerve to another faster performing PC for generating the certificates.
On git.ipfire.org is also a ovpnmain.cgi which I compared with the one on my IPFire. There are also significant differences. Your’s has more lines. So I tried to replace it also. But with that one I find the list of encryption algorithms much shorter (esp. no AES-GCM) and the extended server options are also lacking of several features. So I reversed to the one before. The timestamp of my file is 18.12.2020. It has also not been updated by the Core Update from 135 > 141 > 153. I can not evaluate the differences. Maybe you want to take a look.
