Technical Tip: Utilizing factory and custom certificates in tandem for the FortiGate-to-FortiManager (FGFM) protocol

[alafrance]

Description	This article describes how use to both custom and factory certificates to secure FortiGate to FortiManager (FGFM) protocol communications in situations where some FortiGate model's 'Fortinet Factory' does not contain the serial number in the Common Name Field (CN=) and the FortiManager already manages a large fleet of devices with the default factory certificates.
Scope	FortiManager, FortiGate.
Solution	Starting from FortiManager v7.6.2/v7.4.6/v7.2.10, the fgfm-peercert-withoutsn command is no longer supported, and FortiManager will always check the FortiGate's certificate for the FortiGate Serial Number inside the CN Field. If this field shows a different value from the Serial Number seen on the Fortigate , the connection is rejected. Due to this change in behavior, certain on-demand/pay-as-go FortiGate cloud instances (OCI PAYG,RAXONDEMAND,ALIOND) are no longer able to communicate with the FortiManager as the Fortinet_Factory certificate on these model's do not contain the serial number in the CN Field of the certificate. This is due to a fundamental differences in how these instances are deployed/provisioned by these cloud providers. These differences currently do not allow a signed factory default certificate (containing the serial number) to be securely retrieved from FortiCare/FortiGuard by the FortiGate instance and a generic factory certificate is used instead.  It is however possible to restore communication by making use of custom certificates: Technical Tip: Setup custom certificate for FGFM protocol. This article will focus on a scenario where a FortiManager is already managing a large fleet of physical FortiGates and the administrator desires to continue using the default Fortinet_Factory for those devices but wishes to use custom certificates for an impacted On-Demand instance to restore management connectivity. This can be achieved with minimal configuration changes across the fleet of devices due to the fact that the FortiManager will implicitly trust the Certificate Authority that signed the Fortinet_Factory certs even if a custom Certificate Authority for FGFM protocol communications is specified. The FGFM certificate validation is done bidirectionally: Certificate sent from the FortiGate to the FortiManager. Certificate sent from the FortiManager to the FortiManager. The key detail is that the certificates sent in both directions are validated independently and thus do not need to be signed by the same Certificate Authority. This permits an Administrator to only need issuing certificates for specific devices and not the entire managed fleet.  In the above illustration, only the FortiGate instance sends a custom certificate, while the FortiManager sends it's default Fortinet_Factory certificate despite both certificates being signed by different authorities. In this situation, the FGFM tunnel will come up as both sides validate successfully in spite of the CA asymmetry due to the following three factors. FortiOS will trust the issuer of the Fortimanager's Fortinet_Factory by default unless otherwise specified by: config system central-management     set ca-cert "Cert_Name" end FortiManager trusts the custom certificate of the OCI-PAYG Instance due to it being signed by the CA specified in 'set fgfm-ca-cert'. FortiManager also implicitly trusts the CA that signs Fortinet_Factory certificates as long the following default setting is not set to 'enable', the FortiManager will only trust whatever is specified in 'set fgfm-ca-cert'. config system global     set fgfm-cert-exclusive disable end Prerequisites prior to implementation: Certificate Authority to issue certificates. Signed certificate for each VM Instance , these certificates must have the Serial Number of each instance in the Common Name field (CN=) , the following minimum extensions are needed in the certificate: keyUsage=critical,digitalSignature authorityKeyIdentifier=keyid, issuer:always subjectKeyIdentifier=hash basicConstraints=critical,CA:FALSE If on-demand/pay-as-you FortiGate VM instances are in HA, it is recommended to use FortiOS 7.4.8+/7.6.3+ due to a bug (1099346) in earlier versions where 'set local-cert custom_cert_name'  is synchronized across cluster members instead of allowing a unique value per member.  While it is possible to have communication working on earlier versions, this bug can cause the FGFM Protocol connection to stop working after an HA failover. Implementation: Once prerequisites are met (e.g. certificates correctly issued), implementing custom certificates for impacted FortiGate on-demand/pay-as-you-go instances can be done using the following steps. Upload the custom certificate and private key for the FortiGate on-demand/pay-as-you-go instance. Ensure the CA exports both public and private keys (e.g. PKCS#12 file.) Reference : Import a certificate | Fortinet Document Library   Apply the newly uploaded custom certificate for use in FGFM protocol communications on the FortiGate: config system central-management     set local-cert “Custom_Cert” end Repeat Steps 1 & 2 for other FortiGate instances as needed.  Upload the internal CA (e.g. public key only) certificate to the FortiManager. For instructions, see Technical Tip: Import CA certificates in FortiManager or FortiAnalyzer. Apply the following configuration change on the FortiManager to trust the internal CA for FGFM connection: config system global     set fgfm-ca-cert Custom_CA_1 end Debug Commands: On the Fortimanager: diagnose fgfm ? diagnose fgfm install-sessions <----- Installation session list. diagnose fgfm object-list   <----- Object list. diagnose fgfm session-list  <----- Session list. diagnose debug application fgfmsd 255 {filter optional} diagnose debug timestamp enable diagnose debug enable On the FortiGate: diagnose debug application fgfmd -1 diagnose debug console timestamp enable diagnose debug enable