Description
This article describes a common problem when importing server certificates. An error message is displayed upon importing: 'Certificate file is duplicated for CA/LOCAL/REMOTE/CRL cert'.
This situation can happen when trying to import a certificate that should be used on the FortiGate to allow the FortiGate to identify itself to another end, for example IPSec signatures or HTTP(S) Web server certificates for the Administrative Web Interface (GUI) but also the SSLVPN interface of the FortiGate.
This issue may arise when the certificate has been freshly set or after replacing an existing one. Certificates expire and cannot be renewed. Certificates need to be replaced in order to provide the functionality.
Solution
Background
In order to identify itself to a remote device, the FortiGate needs a unique set of data that:
- is only available to the FortiGate (or server).
- cannot be faked.
- is in the user's control.
This data set is provided by certificates.
Certificates are always created with 'public' and 'private' key material.
This pair of keys belongs together and cannot be used with other pairs. The terms public and private refer to the use of that material:
- Public key material is available for everyone, like certificates of Root Certificate Authorities which are included in the system certificate store for example.
- Private key material is the unique set of data only available to that same entity that uses it for signing data. Signatures cannot be faked, but data signed with a private key can be verified with the matching public key.
Troubleshooting
The error message occurs when trying to import a certificate without private key material.
When a certificate is created the private key material is included, so the entity that provided the certificate will have this material as well.
This is often supplied either in a pair, that is as crt/cer (public) and .key file (private) or with a p12 as bundle file.
Note: Both types can be password protected, but are not necessarily. Software dealing with such files will still request a password for importing/reading, even when there is none.
Be sure to receive the password from the provider as well.
If there is none, leave the password field blank when importing.
It is possible to obtain the private key material as follows:
1) The public certificate authority (for example GlobalSign, Digicert,…) will have the file available as well on the download method CA provided with the certificate.
2) In the certificate has been received from an internal certificate authority, the material should also be available.
It may be needed to contact the responsible person or department to obtain the private key material.
3) A special and valid case is: if the certificate has been created by the 'Generate' button on the certificates page on the FortiGate, it created a 'certificate signing request' (CSR) which was sent to a certificate authority for signing. Then, only the public key material can be received.
This case is special, because it should not throw the error message above.
The reason is that the private key material has been generated on the FortiGate and was used to generate the CSR. The private key cannot be exported though.
More information on generating a CSR can be found in our Cookbook here.
To import the files, select the 'Import' button on the top and select the appropriate file type, PKCS #12 or 'Certificate' for importing certificate and key file. Choose a descriptive name that would appear in the FortiGate Certificate section.
Examples:
Importing a PKCS #12 bundle (.p12) file:
This is how to import separate files, public certificate and private key material:
When the CSR is created on the firewall, and it is signed manually, make sure that the cert get from the CA is in .cer format, not .crt, (rename it if necessary) and import it as 'Local Certificate'.
Otherwise, the same error will be shown: 'Certificate file is duplicated...'
Otherwise, the same error will be shown: 'Certificate file is duplicated...'
In case of import issues, please contact Fortinet Technical Support.
Notes
The same procedure applies to CA certificates, used for SSL/TLS deep inspection.
The private key material is also needed, but it is not available from a public certificate authority.
Thus case 1) will not be applicable, only 2) and 3) would work.
Use the internal CA to implement either of them.
This article describes how certificates work in a simple overview. Similar messages and procedures are applicable to other products as well.
Related kb articles:
