About Certificates

Certificates match the identity of a person or organization with a method for others to verify that identity and secure communications. They use an encryption method called a key pair, or two mathematically related numbers called the private key and the public key. A certificate includes both a statement of identity and a public key, and is signed by a private key.

The private key used to sign a certificate can be from the same key pair used to generate the certificate, or from a different key pair. If the private key is from the same key pair used to create the certificate, the result is called a self-signed certificate. If the private key is from a different key pair, the result is a regular certificate. Certificates with private keys that can be used to sign other certificates are called CA (Certificate Authority) Certificates. A certificate authority is an organization or application that signs and revokes certificates.

If your organization has a PKI (public key infrastructure) set up, you can sign certificates as a CA yourself. Most applications and devices automatically accept certificates from prominent, trusted CAs. Certificates that are not signed by prominent CAs, such as self-signed certificates, are not automatically accepted by many servers or programs, and do not operate correctly with some Firebox features.

Use Multiple Certificates to Establish Trust

Several certificates can be used together to create a chain of trust. For example, the CA certificate at the start of the chain is from a prominent CA, and is used to sign another CA certificate for an intermediate CA. The intermediate CA can then sign another CA certificate used by your organization. Finally, your organization can use this CA certificate for use with the HTTPS proxy and SMTP proxy content inspection features. However, to use that final certificate at the end of the chain of trust, you must first import all of the certificates in the chain of trust in this order:

CA certificate from the prominent CA or local CA (as type General Use)
CA certificate from the intermediate CA, if applicable (as type General Use)
Signed certificate for proxy content inspection (as type Proxy Authority for outbound, as type Proxy Server for inbound)

It could also be necessary to import all of these certificates on each client device so that the last certificate is also trusted by users.

Certificate chains may contain all or some of these certificate types based on what is required. For example, your certificate chain might not contain an intermediate CA certificate or a local CA certificate.

How the Firebox Uses Certificates

Your Firebox can use certificates for several purposes:

Firebox management session data is secured with a certificate.
Branch Office VPN, Mobile VPN with IPSec, Mobile VPN with L2TP, and Mobile VPN with IKEv2 tunnels can use certificates for authentication.
When content inspection is enabled for outbound HTTPS or SMTP, POP3, or IMAP over TLS traffic, these proxies use a certificate to re-encrypt traffic after it is decrypted for inspection. The resigning certificate can be either the default Proxy Authority Certificate or an imported CA Certificate.
You can use a certificate with an inbound HTTPS proxy to protect a web server on your network.
- You can use the default Proxy Server certificate for this purpose or select a different certificate to use for each proxy.
- This allows you to host several different public-facing web servers and applications behind one Firebox and allow different applications to use different certificates.
When content inspection is enabled for inbound SMTP, POP3, or IMAP over TLS traffic, the proxy uses a certificate to re-encrypt traffic after it is decrypted for inspection. You can use the default Proxy Server certificate for this purpose.
When a user authenticates with the Firebox for any purpose, such as a WebBlocker override, the connection is secured with a certificate.
When RADIUS or Firebox authentication is configured to use WPA Enterprise or WPA2 Enterprise authentication methods.

By default, your Firebox creates self-signed certificates to secure management session data and authentication attempts for Fireware Web UI and for proxy content inspection. To make sure the certificate used for content inspection is unique, its name includes the serial number of your device and the time at which the certificate was created.

Because these certificates are not signed by a trusted CA, users on your network see warnings in their web browsers.

You have three options to remove this warning:

You can import certificates that are signed by a CA your organization trusts (such as a PKI you have already set up for your organization) for use with these features. We recommend that you use this option if possible.
You can create a custom, self-signed certificate that matches the name and location of your organization.
You can use the default, self-signed certificate.

For the second and third options, you can ask network clients to accept these self-signed certificates manually when they connect to the Firebox. Or, you can export the certificates and distribute them with network management tools.

For information on how to export certificates, go to Export a Certificate from Your Firebox.

For information on how to import the certificate to a client, go to Import a Certificate on a Client Device.

For information on how to download and import the certificate from the Certificate Portal on the Firebox, go to Certificate Portal.

Replace or Remove Certificates

When you import a certificate, the existing certificate is replaced. On rare occasions, you might need to manually remove a certificate for these reasons:

A certificate signing request (CSR) is pending and will not be completed
A certificate is expired
A CA certificate exists from a local server that is no longer in use

Do not remove a certificate from your Firebox unless you plan to replace it. If you remove a certificate and do not replace it, the Firebox automatically replaces the missing certificate with a default certificate if the device restarts. If you delete a trusted CA certificate for proxies, some security services might not work.

Certificate Lifetimes and CRLs

Each certificate has a set lifetime when it is created. When the certificate reaches the end of that set lifetime, the certificate expires and can no longer be used automatically. You can also remove certificates manually with Firebox System Manager (FSM).

If you use a certificate for authentication, it is important to track when the certificates expire. This helps to avoid disruptions in critical services such as VPN.

Sometimes, certificates are revoked, or disabled before their lifetime expiration, by the CA. Your Firebox keeps a current list of these revoked certificates, called the Certificate Revocation List (CRL), to verify that certificates used for VPN authentication are valid. If you have WatchGuard System Manager installed, this list can be updated manually with Firebox System Manager (FSM), or automatically with information from a certificate. Each certificate includes a unique number used to identify the certificate. If the unique number on a Web Server, BOVPN, Mobile VPN with IPSec, Mobile VPN with L2TP, Mobile VPN with IKEv2 certificate matches an identifier from its associated CRL, the Firebox disables the certificate.

When content inspection is enabled on a proxy, the Firebox can check the OCSP (Online Certificate Status Protocol) responder associated with the certificates used to sign the content. The OCSP responder sends the revocation status of the certificate. The Firebox accepts the OCSP response if the response is signed by a certificate the Firebox trusts. If the OCSP response is not signed by a certificate the Firebox trusts, or if the OCSP responder does not send a response, then you can configure the Firebox to accept or reject the original certificate.

For more information about OCSP options, go to HTTPS-Proxy: Content Inspection.

Certificate Authorities and Signing Requests

To create a self-signed certificate, you put part of a cryptographic key pair in a certificate signing request (CSR) and send the request to a CA. It is important that you use a new key pair for each CSR you create. The CA issues a certificate after they receive the CSR and verify your identity. If you have FSM or Management Server software installed, you can use these programs to create a CSR for your Firebox. You can also use other tools, such as OpenSSL or the Microsoft CA Server that comes with most Windows Server operating systems.

We recommend that you use third-party software to generate the CSR. This allows the certificate to be used on another Firebox if you upgrade to a newer model, migrate to another Firebox, or return the Firebox for an RMA replacement.

To create a certificate for use with the HTTPS-proxy content inspection feature, you must create a CA certificate that can re-sign other certificates. If you create a CSR and have it signed by a prominent CA, it cannot be used as a re-signing CA certificate for content inspection.

For inbound SMTP TLS content inspection, you can use the default self-signed Proxy Server certificate. If you want external entities to be able to validate your domain, use a public signed certificate.

If you do not have a PKI set up in your organization, we recommend that you choose a prominent CA to sign the CSRs you use, except for the Proxy Authority certificate. If a prominent CA signs your certificates, your certificates are automatically trusted by most users. You can also import additional certificates so that your Firebox trusts other CAs.

For a complete list of automatically trusted CAs, go to Certificate Authorities Trusted by the Device.

In WatchGuard System Manager, the Management Server also operates as a CA. The CA gives certificates to managed Fireboxes when they contact the Management Server to receive configuration updates.