[solved] OpenVPN: Can't generate correct host certificate (RFC3280)

Virtual Private Networks
#1

Hello,

my recently updatet IPFire (Core 135 > 141 > 153) has a problem to generate a correct host certificate.

I received this warning after Core-Update 141:

grafik
grafik1214×194 5.41 KB

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.

grafik
grafik1191×301 24.7 KB

Tried with Hash SHA2 256 Bit and SHA2 512 Bit, as well with encryption AES-CBC (256 Bit) and AES-GCM (256 Bit).

It is suggested to update to the latest release. I thought, Core 153 is the latest release?

Is there a method to completely reset OpenVPN to initial state (virtually a factory reset for OpenVPN only)?

Regards
Simulacron

#2

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.

– Simulacron

#3

Dont think so.

forum
forum1202×198 18.1 KB

Just to make it clear, if we talk about TLS-Authentification-Key, then 2048 bit is normal.

What happens if you use button Generate Diffie-Hellman Parameters 4096 bit?

#4

Hi @simulacron,

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.

#5

Ok. Thanks. Thought, I’d tried forum.ipfire.org also direct and was back on the community site. But I recognize, it’s still viewable.

Reason why I came to this conclusion was that Google showed me e.g. these matches

grafik
grafik635×533 39.1 KB

and every link led me back to the startpage of community.ipfire.org and not to the shown threads on forum.ipfire.org. But not today. Strange.

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.

– Simulacron

#6

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

#7

Hello Adolf,

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.

– Simulacron

2 Likes
#8

Hi @simulacron,

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.

https://github.com/ipfire/ipfire-2.x/blob/master/config/ovpn/openssl/ovpn.cnf

Good luck. I hope the new ovpn.cnf is the solution .

1 Like
#9

Can also confirm there are differences, have also no RANDFILE but the following is missing in yours. Maybe more

extendedKeyUsage = serverAuth
keyUsage = digitalSignature, keyEncipherment

#10

Hi all,
there is a longer history according to this problem. It seems that the update process with Core 115 at that time missed changes in ovpn.cnf but am not sure about that.
The needed changes are in here --> git.ipfire.org Git - ipfire-2.x.git/blobdiff - config/ovpn/openssl/ovpn.cnf
and the complete patch from that time is here --> git.ipfire.org Git - ipfire-2.x.git/commit

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.

openssl x509 -text -in /var/ipfire/ovpn/certs/servercert.pem | grep -A1 'X509v3'

and you should be able to see the “Extended Key Usage” lines like this:

        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
--
            X509v3 Subject Key Identifier: 
                XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
            X509v3 Authority Key Identifier: 
                keyid:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
--
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 Key Usage: 
                Digital Signature, Key Encipherment

Regarding the DH-Parameter: It is a better idea to produce it on another machine with a

openssl dhparam -out dh4096.pem 4096

and upload it then via WUI --> wiki.ipfire.org - Extended usage of CA and keys .

Hope this helps.

Best,

Erik

P.S. The search function in here delivers valid information --> Search results for 'rfc3280' - IPFire Community .

2 Likes
#11

Hello Erik,

thank you for looking in here and your summary.

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.

original_ovpnmain.cgi.tar (217,4 KB)
(again extension tar to remove after download)

Is it safe to continue using this ovpnmain.cgi?

– Simulacron

#12

Hi Simulacron,
you can find here --> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob_plain;f=html/cgi-bin/ovpnmain.cgi;hb=refs/heads/core153 the current actual Core 153 ovpnmain.cgi .

Best,

Erik

#13

Hello all,

problem solved. Finally the ovpnmain.cgi from the last link also fits. Thanks for references and assistance :slightly_smiling_face: :+1:

–Simulacron

1 Like