Related Topics

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 a smaller CA. That smaller CA can then sign another CA certificate used by your organization. Finally, your organization can use this CA certificate to sign another 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:

  1. CA certificate from the prominent CA (as type Other) CA certificate from the smaller CA (as type Other)
  2. CA certificate from the organization (as type Other)
  3. Certificate used to re-encrypt proxy content after inspection (as type Proxy Authority)

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.

How the Firebox Uses Certificates

Your Firebox can use certificates for several purposes:

  • Management session data is secured with a certificate.
  • Branch Office VPN, Mobile VPN with IPSec, and Mobile VPN with L2TP tunnels can use certificates for authentication.
  • When content inspection is enabled for HTTPS traffic or SMTP over TLS, these proxies use a certificate to re-encrypt incoming traffic after it is decrypted for inspection.
  • You can use a certificate with the proxy to protect a web server on your network.
  • 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.

The Proxy Authority certificate must not be deleted and left with no certificate. The Firebox automatically replaces the missing certificate with a default certificate if the device restarts.

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:

  1. 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.
  2. You can create a custom, self-signed certificate that matches the name and location of your organization.
  3. 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, see Export a Certificate from Your Firebox.

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

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

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

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, or Mobile VPN with L2TP 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, see 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.

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 (Certificate Signing Request) and have it signed by a prominent CA, it cannot be used as a CA certificate.

For SMTP TLS encryption, in Fireware OS v11.10.x and lower, you must use a CA certificate that can re-sign other certificates. If you create a CSR (Certificate Signing Request) and have it signed by a prominent CA, it cannot be used as a CA certificate. In Fireware OS v11.11 and higher you can use a CA certificate that can re-sign other certificates, or a self-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 CA certificate. If a prominent CA signs your certificates, your certificates are automatically trusted by most users. WatchGuard has tested certificates signed by VeriSign, Microsoft CA Server, Entrust, and RSA KEON. You can also import additional certificates so that your Firebox trusts other CAs.

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

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

For more information, see Configure the Certificate Authority on the Management Server.

See Also

Create a Certificate with FSM or the Management Server

Create a CSR with OpenSSL

Import a Certificate on a Client Device

Use Certificates with HTTPS Proxy Content Inspection

SMTP-Proxy: TLS Encryption

Certificates for Branch Office VPN (BOVPN) Tunnel Authentication

Certificates for Mobile VPN With IPSec Tunnel Authentication

Certificates for Mobile VPN with IPSec Tunnel Authentication

Manage Device Certificates (WSM)

Manage Device Certificates (Web UI)

Manage Certificates on the Management Server

Give Us Feedback     Get Support     All Product Documentation     Technical Search