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.

Regards
Paul



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=b66b02ab73863bcb9130300d8ef0eecdc51efde3
. 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
> 
> 
>