Thanks Tom, Makes sense for me to take a note of user settings do a fresh install and recreate manually the setup as I have no idea which .ipf file I used to restore so lots of scripts could be affected.In future I will create backups regularly and keep them downloaded into directories named with the core update value. An improvement suggestion would be for the backup script to also build the core update number as well as the date and timestamp into the backup filename. This would provide a helpful reminder to users of what might need to be followed up on. RegardsPaul
Paul Titjen
-------- Original message -------- From: Tom Rymes trymes@rymes.com Date: 29/08/2018 02:16 (GMT+00:00) To: Paul Titjen paul.titjen@ministc.com Cc: ummeegge ummeegge@ipfire.org, development@lists.ipfire.org Subject: Re: Testing core update 123
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 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