When an FGFM connection fails to establish and the FGFM debug log includes a message that contains the text 'unsuitable certificate purpose', then this mostly likely means that the certificate that is being presented by the FortiGate device to FortiManager during TLS negotiation of the FGFM connection does not have the correct Extended Key Usage (EKU) extension.
In the context of the FGFM connection, the FortiGate device takes on the role of a 'client', whilst the FortiManager acts in the 'server' role.
The FGFM connection employs mTLS as a means to authenticate the connecting FortiGate device.
For mTLS, the certificate that is presented to the 'server' (FortiManager) by the 'client' (FortiGate) needs to contain information about the certificate being used for 'clientAuth' purposes; that information will be found in the certificate EKU field.
A lack of 'clientAuth' in the certificate may occur when the certificate has been generated by a 3rd-Party Certificate Authority (CA), rather than the FortiGate's own internal CA. Such a 3rd-party CA could be a well-known public CA but it could also be a private company-internal CA.
Background Information: Whilst this particular error condition may not have occurred in the past with 3rd-party-CA issued certificates, it may now be seen to occur due to a recent change (circa autumn 2025) that took place amongst the Internet community to address some security concerns with certificates issued by public CAs.
Prior to that time, most public CAs issued certificates which by default included intended function descriptions in the EKU for both 'TLS Web Server Authentication' (which is required for a 'server' role certificate) and 'TLS Web Client Authentication' (which is only really applicable for 'client' role certificates).
Public CAs have since changed their certificate issuance process so that their certificates are now only produced with just the 'TLS Web Server Authentication' EKU setting by default.
If the 'TLS Web Client Authentication' EKU is required in a certificate, it now needs to be explicitly requested when the certificate is being generated.
Further explanations about this EKU change from some of the well-known public CAs can be found here from Sectigo and DigiCert respectively:
Note: Whilst this change in certificate issuance processing is being adopted by all the well-know public CAs, it may also be the case that the EKU values used by private company-internal CAs also may now by default just contain the 'TLS Web Server Authentication' EKU value.
The EKU values in the certificate that are (or will be) used in a FortiGate device for the FGFM connection can be checked using either of the following methods:
From the FortiGate GUI:
Use the 'View Details' option on a selected certificate (select the certificate by going to System -> Certificates) and then look for the 'Extensions' section towards the bottom of the displayed details page - check the 'X509v3 Extended Key Usage' entry for a value of 'TLS Web Client Authentication', as shown in the following extract:
From the external machine (which has a copy of the certificate file):
Prior to loading the certificate into FortiGate (or after exporting the certificate from FortiGate), it is possible to use a common SSL tool like 'openssl' to view the full certificate details:
openssl x509 -noout -text -purpose -in <cert-file>
Look for a line that says 'SSL client', as shown in the following extract:
...
Certificate purposes:
SSL client : Yes
...
Alternatively, in the main certificate information that is dumped to the screen, look for the 'X509v3 Extended Key Usage' entry and check that it contains the value 'TLS Web Client Authentication', as shown in the following extract:
...
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Subject Key Identifier
...
Related articles:
| 
