|
If the license of a FortiGate changes due to any reason:
- Renewal of an expired license.
- Extending license features (security fabric, webfiltering, etc).
- Changing from temporally/test license to permanent license.
The FortiGate will reboot to validate the new license against FortiGuard.
During this process, it will rebuild the self-sign 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 the new license, and regenerate self-signed certificates.
- The unit-A will join to 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 it would have the old serial number on it, 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:
diag debug reset
diag debug application fgfm 255
diag debug console time enable
diag debug enable
Debug on FortiManager:
diag debug reset
diag debug application fgfmsd 255 <deviceName>
diag debug time enable
diag 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 does not match with the serial number received on the certificate, the 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 'overwrite 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
Related article:
Technical Tip: How to Enable/Disable HA Override without a failover
|
