Fortigate ssl proxy private keys are different on every backup, diffing not possible

[aseques]

I have a little script that uses scp to download the current configuration to my server, there's a second part of the script that does a diff with both files and warns me when there have been modifications.

I am having an issue with the  private keys for "Fortinet_CA_SSLProxy"  and for "Fortinet_SSLProxy", weird enough the certificates are the same all the time, so i'm a bit lost here. Aren't the backups mean to be identical? (other than the  conf_file_ver)?

[FatalHalt]

I've noticed this too, using the same type of tools. Would be interesting to know why. 

[emnoc]

The priv-key are the same if you  look at the show command the keys would be the same. Execute the show full under config vpn cert local and you will see they are the same. You can also download the certifiacte and private-key and do a comparison using openssl.

Also iirc the  "Fortinet_CA_SSLProxy" is certificate is not unique but the same across version and OS.

[aseques]

Do you know any way to change this behaviour? I've this script running for some time and I'd say that it did not worked like this on 5.0 and earlier. with the diff tool is possible to create a regex to extract the part you are not interested from the diffing (as I am doing with the conf_file_ver), but for  a privatekey (multine, no markup) it would be quite difficult.

Being able save a config without these changing keys would be ok to (of course while keeping my custom keys)

[aseques]

Anyone did come up with a solution? Basically the point of having downloadable configuration files is being able to store them and compare the versions, but that's complicated with current system.

How are you doing your backups?

[jmlux]

Hi,

Any news on this by any chance?

Best regards,

Marki

[aseques]

jmlux wrote:

Hi,

Any news on this by any chance?

Best regards,

Marki

No news on this, unfortunately I cannot open a case directly with fortigate because I only manage the system but don't have the registration details (it's managed by a contractor)

[jmlux · Accepted solution]

I haven't asked support (yet), but I have found out the following:

Different types of configuration output / backup are available (output=backup in this case since everything is a text file, kudos, Fortinet):

[ul]

show (like backup but without certificates)

show full (very verbose, includes default config, and always changing stuff)

execute backup (like "show" but with certificates)[/ul]

You only notice stuff changing when comparing different "show full"s.

Meaning: Since "execute backup" (=the backup function in the GUI) is not a lot more verbose than a simple "show", it follows from that that the always changing information is not required to accomplish an actual restore. So why back it up?

Now those findings would have to be confirmed by someone ;)

[aseques]

jmlux wrote:

I haven't asked support (yet), but I have found out the following:

Different types of configuration output / backup are available (output=backup in this case since everything is a text file, kudos, Fortinet):

[ul]

show (like backup but without certificates)

show full (very verbose, includes default config, and always changing stuff)

execute backup (like "show" but with certificates)[/ul]

You only notice stuff changing when comparing different "show full"s.

Meaning: Since "execute backup" (=the backup function in the GUI) is not a lot more verbose than a simple "show", it follows from that that the always changing information is not required to accomplish an actual restore. So why back it up?

Now those findings would have to be confirmed by someone ;)

I am doing the backup with scp, (see here), so I can have totally automated backups (and the whole changeset). Other than the certificate differences the rest of the information is always the same and I can diff without problems.

In the case of scp, you don't have a choice of what type of backup ar you doing, it's always in the execute backup format, so it can restore a system without issues and leaves the defaults untouched.

Having had this for some months it is really a helpful tool, I could restore configs to formatted devices easily and also track and revert an obscure change that did a colaborator that collateraly affected the ttl timeout.

[aseques]

Since there doesn't seem to be any solution to this I had to resort to using a temp file, so this expression:

grep -v "^[[:alnum:]\=\\\+\/]\{30,64\}" newfile.conf | grep -v "...=" > newfile.tmp

grep -v "^[[:alnum:]\=\\\+\/]\{30,64\}" oldfile.conf | grep -v "...=" > oldfile.tmp

Creates temp files that can be diffed so I know if there are configuration differences.