Importing and using third-party certificates on a Firewall

This article will explain how to use certificates issued by a third-party Certification Authority (CA), such as Let's Encrypt, Comodo, Symantec, Digicert etc. It will also cover how certificates work in general.

Synopsis

The certificates serve two main purposes: To encrypt communication between two entities and to confirm's entity authenticity. The former may be granted by a so-called self-signed certificate, but to authenticate the entity, you need a globally trusted certificate issued by root or intermediate CA. This article will explain how certificates generally achieve this authentication, how to change the certificate's format to work with other devices, including our firewalls, how to import the certificate to your firewall and how certificates should be handled to avoid security risks.

Table of Content

1. How does a certificate work?
2. Self-signed certificates
3. Working with certificates
4. Importing certificates in USG/ATP firewalls
5. Certificate security

How does a certificate work?

Every certificate consists of two parts: The certificate (also called the public key) and the private key. The certificate can be publicly shared and merely contains information about the purposes for which the certificate was issued and to which entity the certificate was issued - this may be your FQDN, E-mail address or other value.

Certificates have a limited validity period - this helps with situations where some old certificate with a private key is dug up somewhere after decades. If the validity was infinite, the certificate could still be used for malicious purposes by anyone who gets their hands on it. As of 2021, it is recommended not to use a validity period over one year. With the advent of automatic reissue mechanisms such as CertBot, this period may become much shorter to further improve security.

Certificates can be revoked in case the private key was leaked - and as a matter of precaution, any security breach that compromised hardware containing private keys should be followed by a certificate revocation and subsequent reissue of new certificates.

Certificates can be issued to various entities, such as FQDN, E-mail, even IP address or given name. While it is technically possible to have wildcard FQDN certificates and those are often preferred by users, keep in mind that in case of a private key leak from a specific service, the wildcard certificate authenticates the whole FQDN - as a result, a leak of the private key on a web server that is used for mere company presentation may as well be used for MITM attacks between Exchange server or CRM system. Keeping certificates independent for each subdomain helps to mitigate the impact of the leak until the certificate gets revoked.

While it is also possible to issue certificates to IP address, doing so is deprecated. The reason behind this is that the IPs can be changed easily compared to FQDN.

The basic principle of certificates is fairly simple. In an example, Alice wants to access Bob's server, but the problem is that she was never there so they could never exchange some common secret to authenticate. How can Alice be sure that she is actually connecting to Bob? This is where Charlie comes into play. Alice knows Charlie and added his certificate to the root certificate repository. Therefore Alice considers Charlie a trusted entity. If Bob has his own certificate and private key issued by Charlie, he can authenticate to Alice and it does not matter that Alice was never in touch with Bob before, because Bob is trusted by Charlie, and since Alice trusts Charlie, she trusts Bob too. This is something called a Chain of Trust.

Let's take a look at the Chain of Trust for our Support Campus web certificate:

Notice there is also another entity called R3. This is called Intermediate CA, while DST Root CA X3 is Root CA. Certificate can have only one root CA, but there can be more Intermediate CAs. Intermediate CA is an entity that has been granted permission to issue certificates for its customers. As long as your PC has DST Root CA X3 certificate in the list of trusted root certificates, it will consider support.zyxel.eu trusted.

Self-signed certificates

By default, our firewalls (and many other devices) use self-signed certificates to establish encrypted TLS connection. Such certificate is reported by well-known error message by browser:

There are two reasons why this happen. The first reason is that the certificate is basically a root CA certificate that is not present in your system. But simply installing it as root CA to your computer won't do the trick, because the certificate is not issued for your IP or domain. The certificate is however suitable for a secure connection, and using it does not possess any security risk as long as its private key is not leaked - the only problem here is that the identity cannot be confirmed.

Working with certificates

Over the years, many certificate formats were developed. The certificates are however still using the same principle and all formats can be converted to other formats.

Certificate formats

The oldest format would be the PEM, which contains the ASCII coded key. The reason behind this is original usage in encrypted mails, where binary certificate might get malformed. PEMs are common in Unix systems and it is likely that your CA sent you a certificate along with a private key in PEM format. Usually uses .pem or .cer file extension.

DER is a Binary form of ASCII PEM format certificate. All types of Certificates & Private Keys can be encoded in DER format. This format supports the storage of a single certificate and does not include a private key for the intermediate/root CA. They have extension .der or .cer and are most often used on Java platforms.

PKCS#7 is a binary format that allows containing certificates or whole certificate Chain of Trust in a single file. However, no private key can be stored in this format. This format is most often used by CAs to provide a complete Chain of Trust. Uses extension .p7b.

PKCS#12, also known as PFX is a format that can contain the whole Chain of Trust and private key as well. Usually, this format is provided by CAs, as it can be secured by a password. Commonly uses .p12 or .pfx extension.

Certificate tools

Windows have an in-built system CLI utility certutil that can be used to convert certificates. Management plugins in Microsoft Management Console also allow the management of certificates.

The open-source utility called OpenSSL is also able to handle and convert certificates. Binaries are available for Windows, Linux and macOS (and many other platforms)

Useful certutil commands:

Merging PEM into PFX:
C:\temp>certutil –MergePFX cert.cer cert.pfx
NOTE: as certutil doesn't allow to specify private key path, the key must be present
in the same directory as certificate, have the same name and .key extension.

Useful OpenSSL commands:

Merging PEM into PFX:
C:\temp>openssl pkcs12 -export -out cert.pfx -inkey key.pem -in cert.pem

Importing certificate in USG/ATP firewalls

The current design (as of June 2021) is restricted to the import of certificates without intermediate keys. Should the certificate contain an intermediate key, the file will be parsed incorrectly and the attempt to use such certificate may result in service unavailability (such as WebGUI). It is a good idea to get the certificate in .pem format and export it into .pfx format using either certutil or OpenSSL. The certificate can be imported, along with its password in the following menu:

Configuration > Objects > Certificates > My Certificates

Certificate security

Every certificate has its respective private key. While a certificate is public information, the private key needs to be handled as a secret - and should not be shared by anyone. Not even with us at Zyxel - the only valid way is to use remote assistance tools such as TeamViewer. When storing the private key in pem format, double-check the permissions to access the private key to prevent its leak. Always use password encryption of pfx format to provide at least some degree of security when exporting certificates. Any certificates with the leaked private key should be revoked immediately.