|
If the license of a FortiGate changes for any reason:
- Renewal of an expired license.
- Extending license features (security fabric, web filtering, etc).
- Changing from a temporally/test license to a permanent license.
The FortiGate will reboot to validate the new license against FortiGuard.
During this process, it will rebuild the self-signed certificates since the serial number of the FortiGate-VM will change.
These certificates include the 'Fortinet_Factory' certificate: the one used for the FortiGate to negotiate the TLS connection with the FortiManager.
If the FortiGate is part of an HA CLUSTER with default settings, it could end in the following error:
- Upload/activate a new license on the primary (unit-A) unit using the GUI.
- The primary (unit-A) will reboot, and the secondary (unit-B) will take the role of the new primary.
- The unit-A will reboot, activate the new license, and regenerate self-signed certificates.
- The unit-A will join the HA now as the secondary.
- The unit-A will sync configurations and certificates with the primary unit (unit-B).
Note: The unit-B certificates have the old serial number.
- The unit-A will rewrite the newly regenerated certificates for the oldest ones.
- Upload/activate the second new license on the primary unit (unit-B). The process will follow this logic:
Note: The unit-B will reboot, regenerate, join as the secondary unit, and sync certificates with the primary unit (unit-A).
At the end of the process, both devices will have the wrong certificates since they would have the old serial numbers on them, and both units have different serial numbers after activating the licenses.
It is important to mention that the 'Fortinet_Factory' CERTIFICATE cannot be forced to regenerate through the CLI.
Run the following CLI debug commands on both sides:
Debug on FortiGate:
diagnose debug reset
diagnose debug application fgfm 255
diagnose debug console time enable
diagnose debug enable
Debug on FortiManager:
diagnose debug reset
diagnose debug application fgfmsd 255 <deviceName>
diagnose debug time enable
diagnose debug enable
This will show that FortiManager is ending the TLS connection due to 'write fatal alert: unknown CA'.
FGFMs: issuer matching...try next if not match... local_issuer(support), remote_CA_subject(support)
FGFMs: Root issuer matched, local=remote=support
FGFMs: ssl_proto.c,642: TLSv1.3 SSLv3/TLS write certificate
FGFMs: ssl_proto.c,642: TLSv1.3 TLSv1.3 write server certificate verify
FGFMs: ssl_proto.c,642: TLSv1.3 SSLv3/TLS write finished
FGFMs: ssl_proto.c,642: TLSv1.3 TLSv1.3 early data
FGFMs: ssl_proto.c,642: TLSv1.3 TLSv1.3 early data
FGFMs: - Cert verification error: self-signed certificate
FGFMs: - Remote issuer: FGVMXXXXXXXXXX -> It will show the OLD/PREVIOUS SERIAL NUMBER
FGFMs: ssl_proto.c,744: TLSv1.3 write fatal alert: unknown CA
FGFMs: ssl_proto.c,759: TLSv1.3 error
FGFMs: ssl_proto.c,__get_error,1519, error=1, errno=0,Success, ssl=n/a.
FGFMs(probing...): Connection was interrupted. sockevents[-1] sslerr[0]
FGFMs(probing...): Cleanup session 0x563159040c00, X.X.X.X.
Since the actual serial numbers do not match the serial number received on the certificate, FortiManager will be considered to be a 'man-in-the-middle' (MITM) attack, and the TLS communication will end.
To solve this issue:
Option 1: Upload licenses in both instances at the same time. Both will reboot, and both will regenerate certificates.
Option 2 (recommended): Change HA settings on both devices to use 'override enable' and set a higher priority only on the unit that will upload the new license first. When it rejoins the HA cluster, it will take the role of the primary unit, and it will not sync previous certificates.
On the primary:
config system ha
set override enable
set priority 255
end
On the secondary:
config system ha
set override enable
end
Option 3: Use the override-wait-time setting to force the primary unit to grab back the master role after the license is loaded and the instance is booted. For this, override settings need to be enabled (there is no need for priority).
On the primary:
config system ha
set override enable
set override-wait timer 10
end
After the reboot of unit-A (primary), FortiGates 'exchange' primary roles for clusters. So Unit-A will grab the master role back and stay that way until the override-wait-time period expires. This will cause the certificates not to be overwritten.
Note: Sometimes after a license change, FortiManager needs a reauthorization.
Related articles:
Technical Tip: How to Enable/Disable HA Override without a failover
Technical Tip: HA override wait timer
|
