Managing HTTPS and MTA certificates

HTTPS certificates (also known as Web or server certificates) are named certificates that the appliance uses to identify itself to the Web browsers running the Web UI, and to allow the Web UI to accept HTTPS connections. MTA certificates are named certificates that allow the appliance to identify itself and to encrypt the emails it forwards to the next-hop downstream MTA.

Note

MTA Certificates are only available on the Email Security — Server appliances.

The system self-signed certificate is the default active HTTPS certificate and the default MTA certificate. You can configure an alternate certificate, which can be a certificate issued by your own organization (also a self-signed certificate) or a certificate issued by a public certificate authority (CA).

You can use the following methods to obtain and install a certificate:

Upload both an existing certificate file and the matching private key file from your local file system. (Web UI only)
Enter the public and private key PEM strings at the command line. (CLI only)
Create your own self-signed certificate. This process automatically generates an internal matching private key that is paired with the certificate.
Manually create a Certificate Signing Request (CSR) to obtain a server certificate from a public certificate authority (CA). (See Obtaining a CA certificate from a trusted public certificate authority (CA).)
Use the Email Security — Server Web UI to create a Certificate Signing Request (CSR) to obtain an MTA certificate from a public certificate authority (CA). This process automatically generates an internal matching private key that is paired with the certificate when you import it, so do not explicitly import a private key with the CA-provided certificate.

Note

The wae_proxy_cert and mvx-cloud-cert may be listed as HTTPS certificates. These are auto-generated certificates used for internal purposes. They are not appropriate for application to HTTPS.

Usage guidelines

Each appliance needs a unique HTTPS certificate and matching private key. The MTA also needs an certificate and matching private key. The system self-signed certificate serves as both the HTTPS and MTA certificate by default.
The certificate and private key must be configured as a Privacy Enhanced Email (PEM) encrypted ASCII string.
The PEM string must be formatted in the following order:
1. Double quotation marks
2. A new line
3. BEGIN delimiter string
4. ASCII block
5. END delimiter string
6. A new line
7. Double quotation marks
Note
You can press Enter in the CLI to add a new line.
If a comment is added, it must follow the final double quotation marks and be on the same line. Any commentary outside the BEGIN and END delimiter strings is ignored.
The following is an example PEM string (with a truncated ASCII block):
```
>" 
>>----BEGIN CERTIFICATE-----
>MIIEujCCA6KgAwIBAgIJAI/1cFcdOeykMA0GCSqGSIb3DQEBBQ
>UAMIGZMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p
>YTERMA8GA1UEBxMITWlscGl0YXMTJDE3GDS9DYEDLO9EWS6Fx=
>.
>.
>.
>----END CERTIFICATE-----
>
>"
```
The active HTTPS certificate uses the reserved name web-cert. The active MTA certificate uses the reserved name mta-cert.
You cannot add a new web-cert or mta-cert certificate if one already exists. You must delete or rename the existing certificate first.
After you add the new certificate, you must explicitly activate it for the Web server or MTA.
The HTTPS certificate you import or create can have a unique name, but it must be renamed to "web-cert" before you can activate it.
The MTA certificate you import or create can have a unique name, but must be renamed to "mta-cert" before you can activate it.
The certificate section of the show configuration CLI command output indicates whether a private key is defined for each certificate. Private key PEM strings are omitted.
If a private key has a passphrase, the key must be converted to an unlocked private key PEM string before it can be imported.

Prerequisites

Operator or Admin access