FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
Article Id 214958



This article describes digital certificates and the use and validation of it.


Certificates come with the use of the Secure Sockets Layer (SSL) or its successor, Transport Layer Security (TLS, the latest version 1.3).


Certificates are required for use with SSL/TLS and so certain standard handling needs to be applied.

It also gives a few examples of file types to care for when handling certificates.




Digital certificates are typically used to build up SSL/TLS tunnels in various products, FortiClient EMS, FortiAnalyzer, FortiGate, FortiNAC, FortiAuthenticator, FortiConnect, FortiWeb, and many more.

All of those use certificates already with the web server so where the graphical user interface is available.


Additional functions like Agents or client applications may also make use of certificates.

A small and incomplete list:


- FortiClient VPN.

- FortiClient Mobility Agent.

- Fortinet FSSO Collector Agent.

- FortiNAC Persistent Agent.

- FortiGate <> FortiClientEMS.




Certificates generally will be used for encrypting payload.

Where the payload is coming from, often does not matter.

One indicator is the 'S' at the end of some protocols. SMTP(S), LDAP(S), and FTP(S) are such examples.


An incomplete list as such:



- SMTPS (and a compatibility idea called 'STARTTLS').

- FTPS (not to be mixed up with SFTP which is FTP over SSH).


- POP3S.





These protocols are working simply by creating a TLS tunnel prior to sending, or transporting, any protocol respective payload.

If the tunnel cannot be established, the payload will NOT be sent. Troubleshooting missing, incorrect data, when the tunnel cannot be established, is not needed. Likewise, when traffic/payload is noted, the tunnel likely has been established.


Then there is RADIUS. Its extensible authentication protocol (EAP) can extend the functionality/security of RADIUS greatly. EAP methods that use TLS: EAP-TLS, EAP-TTLS, EAP-PEAP. The secure RADIUS implementation known as RADSEC, rfc6614, also uses TLS.


Also, there are, since TLS works as a tunnel in which payload is transferred, VPN solutions based on SSL or TLS, that supersede SSL.

OpenVPN, SSLVPN. These are however not compatible with each other as each implementation can be done differently.


There are a number of occasions in which certificates are not used by a server only but also used by a client that is using a certificate to authenticate to a server.



All these certificate exchanges have one thing in common:

- A certificate will be exchanged from node A to another node B.

- Node B will verify whether the certificate is valid or not.




It does not matter which protocol is triggering such a certificate exchange, it does not matter which program is using TLS for the exchange.


The TLS version does not matter as well, and it does not matter which setup is used or in which environment.


It can be that multiple certificates are exchanged from client to server and from server to client (typical direction).


If SSL/TLS is used, there will be a certificate exchange.


Some implementations allow skipping the certificate validation (that is after the exchange). Otherwise, there is no way to bypass this.


One prominent example is a certificate warning in a browser when attempting to connect to a website that a browser fails to validate the certificate for.


If 'advanced options' are used one can connect anyway, with this the user has told the browser to skip the validation for this site now and in the future.


FortiGate also allows as a TLS client for LDAPS to not verify the certificate chain of the certificate sent by the LDAPS server.


Once the TLS tunnel is established, traffic/payload would flow between the nodes. In a packet capture, one would only see encrypted traffic.


That also means, that if encrypted traffic is seen, the tunnel is up and the certificate exchange has succeeded.


The certificate exchange can be monitored via various methods.


- If TLS <v1.3 is used, Wireshark shows the certificate exchange directly. With TLS1.3, the certificate exchange will not be visible anymore.


- In either case, logs are visible from both ends. The respective software should generate appropriate logs, best seen when trying to establish such a tunnel. Mark the timestamps.

In the case of software that is installed on an OS, the logs will have defined locations.


- With Windows, it is often located in the installation directory of that product, but the documentation of the software might give more hints.


- In the case of Linux, a part of it might be included in a file in the directory or subdirectory at /var/log/ or in a directory specified by product documentation.


The exchange should be logged or captured similarly to:


1) TLS Client -> Client Hello -> TLS Server.


Client Hello:

- Contains support ciphers.


2) TLS Server -> Server Hello -> TLS Client.


Server hello:

- Contains chosen cipher (overlaps with the client support ciphers).

- Contains server details.

- Contains server certificate.

- MAY contain a request for a client certificate if configured on the server.


3) TLS Client -> Client Key Exchange -> TLS Server.


- The exchange will lead to a change of cipher spec (encrypted).

- If requested from the server, this message will also contain a certificate from the client.


Typical TLS exchangeTypical TLS exchange



As earlier noted, in TLS1.3 after the Client Hello the Certificate exchange is not visible. The exchange is helpful for troubleshooting.


4) Change Cipher Spec again, the TLS tunnel is now up.


The important part is now the validation of that certificate.

Keep in mind that one node sends a certificate, and the other Node's job is to verify it.


Verification is mainly done against:


1) Certificate chain.

2) Certificate validity period (whole chain).

3) Certificate revocation information.


The listed methods in detail:


1) Certificate Chain:


A certificate chain is a link of an end entity certificate (web server certificate or client certificate for example) to another certificate that issued this same certificate. This issuing certificate usually goes by the name of Certificate Authority (CA).


With the example of a server certificate, a chain typically looks like this:


- Server certificate.

- Server certificate is issued by an intermediate CA certificate, also called subordinate CA.

- Subordinate CA is issued by a root CA.


In other words: The root CA issues an intermediate CA certificate. The intermediate CA certificate issues a server certificate.


Certificate chainCertificate chain


More detailed: The 'issuing' is actually the process of signing a public key.

A certificate consists of a public and a private key. This is called a key pair.

The keys belong to each other and cannot be exchanged.


This is a feature that makes certificates and key pairs secure to use while the key cannot be faked.

The two keys are:


- A public key that is supposed to be available to everybody. In some documentations abbreviated as 'pubkey'.

- A private key that stays with this entity only (a web server, an end user as client). In some documentations abbreviated as 'privkey'.


The unique is that data encrypted with one of these two keys can be only decrypted with the other key.

Data encrypted with the private key can be decrypted with the fitting public key.

Data encrypted with the public key can be decrypted with the fitting private key.


The keys can be copied, but a fake key, to imitate the private key fitting this keypair, cannot be easily created. Side note: Usage of private and public keys applies to the SSH protocol as well.


The illustration above shows the actions of the private key, signing the other certificates' public key.

So it encrypts data on the public key of the certificate next in the chain.


On the other side, the signatures, so the encrypted data is decrypted/verified with the public key, belonging to the key pair that created the encrypted data/signature.

The signature decryption with the public key can only work if the public key is available.


The strength of a key will indicate how safe it is that one cannot break the security and fake a key in order to decrypt data with a key that does not belong to this key pair.

Typical key lengths are RSA 2048bit, but more and more RSA 4096.

Additionally, ECDSA keys are of much smaller size, 256 bit for example.


The root CA will sign the intermediate key pair's public key using its private key.

This signature is a data block that is encrypted with the private key of the signer.

It can be decrypted with the public key of the signer. Another public key cannot be used to decrypt the data.


To verify that a certificate was signed (or issued) by a specific authority certificate the public key is required.


The public keys of certificates are distributed to clients in the 'Trusted root certificate authority store'.

Web browsers and operating systems have a pre-filled store with the public keys of the known certificate authorities.


If an error message is presented for an 'unknown CA', it means that the verification of the chain failed as the client is missing a public key in this certificate chain.


There is no difference in handling certificates for different browsers or operating systems such as Microsoft Windows, Apple macOS, Linux, Android, etc. The UI of course will be different.


Web servers typically send their server certificate, and all intermediate certificates up to, but not including the root CA public key. Some may as well send the root CA certificate with them.

In both cases:


- The root CA must be installed on the client as a 'Trusted root certificate authority'.

- The receiving node must be able to complete the chain of certificates.



The chain may consist of a minimum of two certificates, root CA and server certificate, but may as well contain a root CA, three intermediate CAs, and a server certificate.



While possible, there is no relation between siblings, so a chain may branch off.

This is possible but unusual. A CA certificate may sign two or more intermediate CA certificates.


Server certificates signed by the different intermediate CAs will strictly be validated by the hierarchy of the certificate chain.


The other intermediate CA certificate will be unusable for verification of a server certificate.


2) Certificate validity period (whole chain).


The created signature has a validity period.

It has a validity start date and a validity end date.

Outside this range, the signature or the certificate with this signature is not valid.


Note that the private key has no validity period and can be used indefinitely in order to create newer valid signatures.


A private key should still be changed at some intervals as it cannot be fully known if another third party may have gained access to the private key at some point.


Replacing it is a security measure and does not add up to the work tasks rather than renewing a server certificate.

As such replacing the web server's certificate is the standard method when the certificate validity period has come to an end.

It is a good measure to have reminders in place to be alerted for the expiration, rather than get notified of end users facing browser warnings.


3) Finally, a certificate contains certificate revocation information.


The process of revocation is needed in case a valid certificate needs to be invalidated.

A valid reason is that the private key has been compromised by a third party or there was another issue with the use of this certificate.


This is again a method for one node to check the validity of the certificate sent by another node.

A received certificate will be checked against its revocation status and, if revoked, rejected. A warning will be issued.


The revocation information is either provided with a Certificate Revocation List (CRL), which is a list of certificate serial numbers issued by this CA or against an Online Certificate Status Protocol (OCSP) server.


Both methods are intended to enable the client to check the certificates' revocation status.


These methods are common among TLS nodes.

The handling of a certificate for the web server will only differ in the UI meant to import the certificate, but devices like FortiGate, FortiAnalyzer, FortiNAC, and FortiWeb all follow the same rules.


One special example is Deep Packet Inspection (DPI). This differs only in one way:

In the illustration above with the signatures, the 'server certificate' is not used, but another certificate with CA properties, the same as rootCA or the subCA.


Certificate chain on DPICertificate chain on DPI


This scheme is exactly the same, with the exception of the certificate that is the lowest in the chain.

The deep packet inspector needs to be a TLS client to the server but also needs to be a TLS server to the actual client.


This is no different from a 'Man in the middle' (MITM) attack.

In a normal case, certificate chain trust will prevent this from happening as the DPI CA certificate MUST be known to the client.


The public key must be imported on the end station. DPI CAs are typically custom local CAs, not in the end-user key store.

Public CAs that are trusted by everybody does not issue CA certificates.


If DPI is intended for managed clients, the public keys for the certificate(s) can be pushed to the managed clients. Unmanaged clients will have no easy way of receiving public keys.


Note on file types when handling certificates.


When handling certificates, various file types and contents and 'encodings' can be seen. Very common is the base64 encoded certificate (for Microsoft certificate export "CER encoded").


Public certificate key material will start with:

'-----BEGIN CERTIFICATE-----' and end with '-----END CERTIFICATE-----'.
Private certificate key material will start with (might differ depending on the key algorithm):

'-----BEGIN RSA PRIVATE KEY-----' and end with '-----END RSA PRIVATE KEY-----'.


The certificates are stored in certain file formats and extensions.

Public keys come usually with a '.cer'/'.crt' extension, sometimes as '.pem'.

Private keys come either as a separate file as '.key' or as a bundle file together with the public key in a PKSC#12 format, file extension '.p12'. They might also be stored as '.pfx'.


In order to use a certificate for identification it is required to have the private key and it is necessary to have either the .key file or a .p12.


A special case is a certificate signing request, that comes with a '.csr'. It is created by a private key on the device that requires one to get a full certificate, for example, a FortiGate can create a certificate signing request. The CSR will have to be signed with a CA's private key, resulting in a public key and a .cer/.crt file. This can ONLY be imported to the device that issued the CSR. In the case of using a CSR, NO private key will be visible or exposed.


An example of the common file types, which can be seen when receiving a certificate from your CA:


- fortigate.crt.
- fortigate.p12.
- fortigate.pem.
- fortigate.key.
- fortigate.pfx.




crt = public key.

p12 = public + private key.

pem = public key.

key = private key.

pfx = public + private key.


When importing certificates, make sure to have either:


- a CSR from the requesting device and import the public key back to it again.

- the private + public key material for the device that needs to identify itself with certificates.


There are free tools available to work with certificates. Note that these tools are not related to Fortinet, and are generally available and free to use. These are not supported or endorsed by Fortinet.




NMAP is a network scanner and the use of a network scanner may be prohibited in the environment of choice. If unsure, do not run this.


A syntax example of receiving the supported TLS ciphers from a server:


nmap --script ssl-enum-ciphers <address> -p <port>




A syntax example of openSSL to see a TLS server response and the certificates it sends:


openssl s_client -showcerts -connect <address>:<port>


Example output header:


openssl s_client -connect
depth=2 C = US, O = DigiCert Inc, OU =, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
verify return:1
depth=0 C = US, ST = California, L = Sunnyvale, O = "Fortinet, Inc.", CN = *
verify return:1
Certificate chain
0 s:C = US, ST = California, L = Sunnyvale, O = "Fortinet, Inc.", CN = *
  i:C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
1 s:C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
  i:C = US, O = DigiCert Inc, OU =, CN = DigiCert Global Root CA
2 s:C = US, O = DigiCert Inc, OU =, CN = DigiCert Global Root CA
  i:C = US, O = DigiCert Inc, OU =, CN = DigiCert Global Root CA


This is followed by the actual certificate data of the server, and if 'showcerts' was included, the intermediate CA certificates. The chain is displayed here, showing the link from 0 (server certificate) to 2 (root certificate, self-signed). 's' indicates the 'subject', the name of the certificate, valid for the subdomain of ''. 'i' indicates the certificate that signed this certificate.


This can also be applied to the special TLS case that allows an unencrypted header exchange but allows asking for encryption - STARTTLS. It was made for compatibility when transitioning to SSL/TLS and is still typical for LDAP, SMTP, and FTP.


HTTP does not offer STARTTLS. While STARTTLS is possible, it is a good idea to enforce encryption, rather than making it optional.


openssl s_client -showcerts -starttls smtp -connect <address>:<port>


Related Articles about certificates and respective implementations on Fortinet Products:


- FortiNAC:


- FortiMail:


- FortiGate:


- FortiAuthenticator - special case, as it can:


- act as a CA.

- use CA certificates as TLS clients.

- act as TLS server, for web UI but also as TLS server as RADIUS server. Secure TLS sessions are established and encapsulated in RADIUS.