Visitor III

Solved

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

Forum|Forum|10 years ago
July 2, 2015
4 replies
12770 views

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)?

5.2

Best answer by jmlux

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 ;)

FatalHalt

New Member

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

emnoc

New Member

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.

asequesAuthor

Visitor III

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)

asequesAuthor

Visitor III

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

New Member

Hi,

Any news on this by any chance?

Best regards,

Marki

asequesAuthor

Visitor III

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)

jmluxAnswer

New Member

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 ;)

asequesAuthor

Visitor III

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.

asequesAuthor

Visitor III

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.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded