Insight about how digital certificates use and validation

This article tries to give more insight into digital certificates, their use, and validation.

Scope

This applies to multiple products. Digital certificates are typically used to build up TLS tunnels in various products, FortiClientEMS, FortiAnalzyer, FortiGate, FortiNAC, FortiAuthenticator, FortiWeb, and many more.

All of them 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.

Solution

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), FTP(S) are such examples.

An incomplete list as such:

• LDAPS.
• SMTPS (and a compatibility idea called ‘STARTTLS’).
• FTPS (not to be mixed up with SFTP which is FTP over SSH).
• HTTPS.
• POP3S.
• IMAPS.
• SIPS.
• XMPPS.

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.

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 supersedes 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 a node A to another node B.
• Node B will verify whether the certificate is valid or not.

Note: 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 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 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 case of a 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 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:

Step 1: TLS Client >>> Client Hello >>> TLS Server

Client Hello:

• Contains support ciphers.

Step 2: TLS Server >>> Server Hello >>> TLS Client

Server hello:

• Contains chosen cipher (overlap with the client support ciphers).
• Contains server details.
• Contains server certificate.
• MAY contain request for client certificate, if configured on the server.

Step 3: TLS Client >>> Client Key Exchange >>> TLS Server

• 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.

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

Step 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, 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:

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:

1. Server certificate.
2. 1) is issued by an intermediate CA certificate, also called subordinate CA.
3. 2) 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.

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 webserver, an end user as client). In some documentations abbreviated as ‘privkey’.

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.

Date 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.

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 do 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 as Microsoft Windows, Apple MAC OS, Linux, Android, etc. The UI of course will be different.

Webservers typically send their server certificate, and all intermediate certificates up to, but not including the root CA public key.

The root CA must be installed on the client as ‘Trusted root certificate authority’.

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

Note: While possible, there is no relation between siblings, so a chain that may branch off. This is possible but unusual. A CA certificat emay 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.

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 know 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.

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 to 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 webserver will only differ in the UI meant to import the certificate, but devices like FortiGate, FortiAnalyzer, FortiNAC, 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, same as rootCA or the subCA.

This scheme is exactly the same, with the exception of the certificate lowest in 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 to a ‘Man in the middle’ (MITM) attack.

In a normal case, certificate chain trust will prevent this from happened 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 users key store.

Public CAs that are trusted by everybody do 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 the public keys.

There are free tools available to work with certificates. Note that these tools are not relatd to Fortinet and are generally available.

These are not supported by Fortinet.

nmap: https://nmap.org/

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>

openSSL: https://www.openssl.org/

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

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

This can 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 TLS and is 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>