Hi, Thanks for the feedback. That certainly sorted the issue and the crypto warning has now gone. The root cause was that my original clean install of 2.21 core120 was then amended by an old 2.19 backup .ipf file. This has then put back an old version of /var/ipfire/ovpn/openssl/oven.cnf so adding those extended key usage lines back in and making new certs did the trick. I have been caught out before by this restore of an old backup on a newer version of ipfire. My old restore had an include of a php extension in the Web server conf. After the restore Web interface disappeared on reboot due to apache failing the startup. Using command line soon fixed it once having worked out the cause. This brings me to the backup ISO not working. Looking at the script it seems that it is downloading the ISO from ipfire download website with the core update number used in the source URL - the 123 iso is not yet available to download there and only the stable versions hence the fail. I am sure it works with 122. If all it does is get a clean iso then that still leaves the issue of breaking a clean install by restoring an old backup .ipf or does it build a new distribution based on the iso and the existing configuration files as a unique ISO for instant recreate of a system. No real issues then as explanations found. 123 is running nicely.Thanks for all the good work and help. Paul Titjen
-------- Original message -------- From: ummeegge ummeegge@ipfire.org Date: 28/08/2018 20:00 (GMT+00:00) To: development@lists.ipfire.org Subject: Re: Testing core update 123
Hi Paul, an thanks for your feedback. Causing the OpenVPN messages:
Am Dienstag, den 28.08.2018, 18:11 +0100 schrieb Paul Titjen:
OpenVPN Initially had the two crypto warnings so deleted all the cert data and then generated new DH parameters with 3076 value. Then generated new certificate data using the 3076 value. This removed the DH size warning but still leaves the following: Cryptographic warning Your host certificate is not RFC3280 compliant. Please update to the latest IPFire version and generate as soon as possible a new root and host certificate. All OpenVPN clients needs then to be renewed! I looked for any settings that I could apply in web GUI to set extendkeyusage with TLS Web Server Authentication in the cert generation to make the warning go away but could not find a way to do this.
The needed changes are already shipped https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=b66b02ab73863bcb9130300d... . To get the needed changes to your certificates and configuration, you will need to renew the complete x509 which will also reset all existing clients. You can find in here https://forum.ipfire.org/viewtopic.php?t=18852#p108144 a more detailed discussion about this topic whereby OpenVPN provides some infos also in here https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#a--ns-cert-type .
It is time until OpenVPN version 2.5 but ns-cert-type will be dropped then.
+ # Warning if certificate is not compliant to RFC3280 TLS rules + if (-f "${General::swroot}/ovpn/certs/servercert.pem") { + my $extendkeyusage = `/usr/bin/openssl x509 -noout -text -in ${General::swroot}/ovpn/certs/servercert.pem`; + if ($extendkeyusage !~ /TLS Web Server Authentication/) { + $cryptowarning = "$Lang::tr{'ovpn warning rfc3280'}"; + goto CRYPTO_WARNING; + } + }
+ CRYPTO_WARNING: Is OpenVPN going to require critical extends on the certs in the future?
Yes, see above.
Hope this somewhat limited testing information helps.
Great, and thanks.
Regards, Paul
I have had this same issue with restoring an old backup to a newer version. A machine dies one core 118, say, so you download 119 because that is the current, and you don’t remeber what core version the backup is from.
Then, the changes that were applied as part of the upgrade process haven’t been run against the restored files and you have issues like the php file causing Apache to not run.
I have repaired this problem in the past by forcing pakfire to think the system is running the old version still and then making it reapply the updates.
Tom
On Aug 28, 2018, at 5:29 PM, Paul Titjen paul.titjen@ministc.com wrote:
Hi,
Thanks for the feedback. That certainly sorted the issue and the crypto warning has now gone. The root cause was that my original clean install of 2.21 core120 was then amended by an old 2.19 backup .ipf file. This has then put back an old version of /var/ipfire/ovpn/openssl/oven.cnf so adding those extended key usage lines back in and making new certs did the trick.
I have been caught out before by this restore of an old backup on a newer version of ipfire. My old restore had an include of a php extension in the Web server conf. After the restore Web interface disappeared on reboot due to apache failing the startup. Using command line soon fixed it once having worked out the cause.
This brings me to the backup ISO not working. Looking at the script it seems that it is downloading the ISO from ipfire download website with the core update number used in the source URL - the 123 iso is not yet available to download there and only the stable versions hence the fail. I am sure it works with 122. If all it does is get a clean iso then that still leaves the issue of breaking a clean install by restoring an old backup .ipf or does it build a new distribution based on the iso and the existing configuration files as a unique ISO for instant recreate of a system.
No real issues then as explanations found. 123 is running nicely. Thanks for all the good work and help.
Paul Titjen
-------- Original message -------- From: ummeegge ummeegge@ipfire.org Date: 28/08/2018 20:00 (GMT+00:00) To: development@lists.ipfire.org Subject: Re: Testing core update 123
Hi Paul, an thanks for your feedback. Causing the OpenVPN messages:
Am Dienstag, den 28.08.2018, 18:11 +0100 schrieb Paul Titjen:
OpenVPN Initially had the two crypto warnings so deleted all the cert data and then generated new DH parameters with 3076 value. Then generated new certificate data using the 3076 value. This removed the DH size warning but still leaves the following:
Cryptographic warning Your host certificate is not RFC3280 compliant. Please update to the latest IPFire version and generate as soon as possible a new root and host certificate. All OpenVPN clients needs then to be renewed!
I looked for any settings that I could apply in web GUI to set extendkeyusage with TLS Web Server Authentication in the cert generation to make the warning go away but could not find a way to do this.
The needed changes are already shipped https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=b66b02ab73863bcb9130300d... . To get the needed changes to your certificates and configuration, you will need to renew the complete x509 which will also reset all existing clients. You can find in here https://forum.ipfire.org/viewtopic.php?t=18852#p108144 a more detailed discussion about this topic whereby OpenVPN provides some infos also in here https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#a--ns-cert-type .
It is time until OpenVPN version 2.5 but ns-cert-type will be dropped then.
# Warning if certificate is not compliant to RFC3280 TLSrules
if (-f "${General::swroot}/ovpn/certs/servercert.pem") {my $extendkeyusage = `/usr/bin/openssl x509 -noout-text -in ${General::swroot}/ovpn/certs/servercert.pem`;
if ($extendkeyusage !~ /TLS Web ServerAuthentication/) {
$cryptowarning = "$Lang::tr{'ovpn warningrfc3280'}";
goto CRYPTO_WARNING;}}CRYPTO_WARNING:Is OpenVPN going to require critical extends on the certs in the future?
Yes, see above.
Hope this somewhat limited testing information helps.
Great, and thanks.
Regards, Paul
Thanks for reporting back,
Am Dienstag, den 28.08.2018, 22:29 +0100 schrieb Paul Titjen:
Hi,
Thanks for the feedback. That certainly sorted the issue and the crypto warning has now gone. The root cause was that my original clean install of 2.21 core120 was then amended by an old 2.19 backup .ipf file. This has then put back an old version of /var/ipfire/ovpn/openssl/oven.cnf so adding those extended key usage lines back in and making new certs did the trick.
This behavior has been fixed https://cgit.ipfire.org/ipfire-2.x.git/commit/?id=291bfda71eb40a20dd4db77bac... since we excluded ovpn.cnf from the backup but that´s only one part since a backup do includes the old certificates with the old key usage of the digitalSignature in it so they need to be renewed in that case.
I have been caught out before by this restore of an old backup on a newer version of ipfire. My old restore had an include of a php extension in the Web server conf. After the restore Web interface disappeared on reboot due to apache failing the startup. Using command line soon fixed it once having worked out the cause.
This brings me to the backup ISO not working. Looking at the script it seems that it is downloading the ISO from ipfire download website with the core update number used in the source URL - the 123 iso is not yet available to download there and only the stable versions hence the fail. I am sure it works with 122. If all it does is get a clean iso then that still leaves the issue of breaking a clean install by restoring an old backup .ipf or does it build a new distribution based on the iso and the existing configuration files as a unique ISO for instant recreate of a system.
I think the core number problem in the URL should be fixed too https://cgit.ipfire.org/ipfire-2.x.git/commit/?id=f32cbd89d9990b2a1017b7ad19...
Best,
Erik
-
Paul Titjen -
Tom Rymes -
ummeegge