Description
This article describes how to import a remote certificate from an Azure Enterprise Application to a FortiGate running FIPS-CC firmware as well as discussing a requirement/restriction that exists only in FIPS-CC mode.
Scope
FortiGate FIPS-CC firmware, Azure Enterprise Application for SAML authentication.
Solution
FortiGates running certain FIPS-CC firmware do not allow certificates to be imported if they are missing the Basic Constraints extensions. This may impact features where a remote certificate is required, such as the certificate used by a SAML Identity Provider (IdP) to sign assertions and prove their authenticity to the SAML Service Provider (SP).
Because of this restriction, uploading certificates that lack the Basic Constraints extension to a FIPS-CC-enabled FortiGate can result in the error message 'CRL/certificate file doesn't matched CA imported' being shown on-screen (when done through the Web GUI). When attempting to load the certificate via the CLI, admins may instead encounter 'Return code -651'. This error can also be observed if the Root and Intermediate certificates (if any) are not imported into FortiGate.
This article focuses on the SAML feature with Azure as the IdP. However, other IdPs will also experience the same issue since many default application certificates do not contain a Basic Constraints extension.
The solution is to import a valid certificate with Basic Constraints to the IdP Application, and then use the same certificate as the 'Remote IdP Certificate' in the FortiGate configuration.
The certificate can be issued by an internal or a public Certification Authority. In the example below, FortiAuthenticator is used as a Certification Authority.
The Basic Constraint 'Subject Type = End Entity', which means this is not a CA certificate. Therefore, the 'Path Length Constraint' is 'None' because it is only applicable to CA Certificates. The following is an example of a certificate that meets the Basic Constraint requirement:
To import a certificate into Azure that can be used for SAML signing, use the following steps:
- Generate a new certificate with the private key in 'p12' or 'pfx' format.
- In Azure Portal, edit the Enterprise Application, navigate to the 'Single sign-on' section, select 'Edit' in section 3 ('SAML Certificates').
- In the SAML Signing Certificate pop-up window, select the 'Import Certificate' button, then browse to the certificate file. If a password was set during the export of the .p12 certificate file, then provide the password at this stage.
- By default, after importing the certificate, its status remains 'Inactive'. Select the three-dot menu and then select 'Make certificate active' to enable the certificate.
- Download the new certificate to be imported to FortiGate (this will download the certificate only without the private key, which is correct for this use case).
- Import the new certificate to FortiGate as a 'Remote Certificate'.
If the FortiGate is in FIPS-CC mode, any missing intermediate or root certificates will generate the error 'CRL/certificate file doesn't have matched CA imported' when trying to import a 'Remote Certificate'. To avoid this, import the missing certificates in the chain before importing the IdP certificate.
- Optionally, rename the certificate in the CLI after importing to give it a more recognizable name:
config vpn certificate remote
rename REMOTE_Cert_1 to AZURE-FIPS
end
- Apply the new certificate to 'Identity Provider Configuration' under User & Authentication -> Single Sign-On.
Note:
The ability to import its own certificate to the SAML Application depends on the IdP, and the procedure may vary.
For example, for Okta, consult the Okta documentation.
Google Cloud Platform and Cisco DUO may not support this feature.
This restriction for end-entity certificates only applies to some FIPS-CC firmware branches. On a FortiGate running in FIPS-CC mode but non-FIPS firmware 7.0.14, v7.2.6, v7.4.1 or later, this restriction does not apply. See Issue ID# 919901 Resolved Issues for reference.
