The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes how to create a certificate for use with TLS, activate inbound / outbound TLS, and troubleshoot issues on the Cisco ESA.
There are no specific requirements for this document.
This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
The TLS implementation on the ESA provides privacy for point-to-point transmission of emails through encryption. It allows an administrator to import a certificate and private key from a Certificate Authority (CA) service, or use a self-signed certificate.
Cisco AsyncOS for Email Security supports the STARTTLS extension to Simple Mail Transfer Protocol (SMTP) (Secure SMTP over TLS).
Tip: For more information about TLS, refer to RFC 3207.
Note: This document describes how to install certificates at the cluster level with the use of the Centralized Management feature on the ESA. Certificates can be applied at the machine level as well; however, if the machine is ever removed from the cluster and then added back, the machine-level certificates are lost.
An administrator wants to create a self-signed certificate on the appliance for any of these reasons:
The ESA comes preconfigured with a demonstration certificate that can be used in order to establish TLS connections.
Caution: While the demonstration certificate is sufficient for the establishment of a secure TLS connection, be aware that it cannot offer a verifiable connection.
Cisco recommends that you obtain an X.509, or Privacy Enhanced Email (PEM) certificate from a CA. This is also referred to as an Apache certificate. The certificate from a CA is desirable over the self-signed certificate because a self-signed certificate is similar to the previously mentioned demonstration certificate, which cannot offer a verifiable connection.
Note: The PEM certificate format is further defined in RFC 1421 through RFC 1424. The PEM is a container format that can include only the public certificate (such as with Apache installs and CA certificate files /etc/ssl/certs) or an entire certificate chain, to include public key, private key, and root certificates. The name PEM is from a failed method for secure email, but the container format that it used is still active and is a base-64 translation of the X.509 ASN.1 keys.
The option to import your own certificate is available on the ESA; however, the requirement is that the certificate be in PKCS#12 format. This format includes the private key. Administrators do not often have certificates that are available in this format. For this reason, Cisco recommends that you generate the certificate on the ESA and have it properly signed by a CA.
If a certificate that already exists has expired, skip the Deploying Self-Signed Certificates section of this document and re-sign the certificate that exists.
Tip: Refer to the Renew a Certificate on an Email Security Appliance Cisco document for more details.
This section describes how to generate a self-signed certificate and Certificate Signing Request (CSR), provide the self-signed certificate to a CA for signing, upload the signed certificate to the ESA, specify the certificate for use with the ESA services, and back up the appliance configuration and certificate(s).
To create a self-signed certificate via the CLI, enter the certconfig command.
To create a self-signed certificate from the GUI:
Note: The system hostname does not affect the TLS connections in regards to being verifiable. The system hostname is shown in the top-right corner of the appliance GUI, or from the CLI sethostname command output.
Caution: Remember to submit and commit your changes before you export the CSR. If these steps are not completed, the new certificate is not committed to the appliance configuration, and the signed certificate from the CA cannot sign, or be applied to, a certificate that already exists.
To submit the self-signed certificate to a CA for signing:
The CA then generates a certificate in PEM format.
Note: For a list of CA providers, refer to the Certificate authority Wikipedia article.
After the CA returns the trusted public certificate that is signed by a private key, upload the signed certificate to the ESA.
The certificate can then be used with a public or private listener, an IP interface HTTPS service, the LDAP interface, or all outbound TLS connections to the destination domains.
To upload the signed certificate to the ESA:
Tip: You can use the OpenSSL toolkit, a free software program, in order to convert the format.
Note: When you upload the new certificate, it overwrites the current certificate. An intermediate certificate that is related to the self-signed certificate can also be uploaded.
Caution: Remember to submit and commit the changes after you upload the signed certificate.
Now that the certificate is created, signed, and uploaded to the ESA, it can be used for the services that require certificate usage.
Complete these steps in order to use the certificate for the inbound TLS services:
Complete these steps in order to use the certificate for the outbound TLS services:
Complete these steps in order to use the certificate for the HTTPS services:
Complete these steps in order to use the certificate for the LDAPs:
To use the certificate for URL filtering:
Do you want to set client certificate for Cisco Web Security Services Authentication?
Ensure that the appliance configuration is saved at this time. The appliance configuration contains the completed certificate work that has been applied via the previously described processes.
Complete these steps in order to save the appliance configuration file:
Note: This process saves the certificate in PKCS#12 format, which creates and saves the file with password protection.
In order to activate TLS for all inbound sessions, connect to the web GUI, choose Mail Policies > Mail Flow Policies for the configured inbound listener, and then complete these steps:
The mail flow policy for the listener is now updated with the TLS settings that you have chosen.
Complete these steps in order to activate TLS for inbound sessions that arrive from a select set of domains:
The mail flow policy for the Sender Group is now updated with the TLS settings that you have chosen.
Tip: Refer to this article for further information on how the ESA handles TLS verification : What is the algorithm for certificate verification on the ESA?
In order to activate TLS for outbound sessions, connect to the web GUI, choose Mail Policies > Destination Controls, and then complete these steps:
TLS works with a self-signed certificate, however if TLS verification is required by the sender, a CA signed certificate would need to be installed.
TLS Verification can fail even though a CA signed certificate was installed on the ESA.
In these cases, it is recommended to verify the certicate via the steps in the Verify section.
In order to verify the CA signed certificate, apply the certificate to the ESA GUI HTTPS service.
Then, navigate to the GUI of your ESA in your web browser. If there are warnings when you navigate to https://youresa, then the certificate is likely improperly chained, like missing an intermediate certificate.
Before test, ensure the certificate to be tested is applied at the listener where your appliance receives Inbound mail.
Third-party tools such as CheckTLS.com and SSL-Tools.net can be used to verify the proper chaining of the certificate.
Example of CheckTLS.com Output for TLS-Verify Success
Example of CheckTLS.com Output for TLS-Verify Failure
Cert Hostname DOES NOT VERIFY (mailC.example.com != gvsvipa006.example.com)
Note: If a self-signed certifcate is in use, the expected result in "Cert OK" column is "FAIL".
If a CA signed certificate is in use and TLS-verify still fails, verify that these items match:
If a CA signed certificate was installed and you see errors, continue to the next section for information on how to troubleshoot the issue.
This section describes how to troubleshoot basic TLS issues on the ESA.
Look for duplicate intermediate certificates, especially when current certificates are updated instead of a new certificate creation. The intermediate certificate(s) have possibly changed, or have been improperly chained, and the certificate possibly uploaded multiple intermediate certificates. This can introduce certificate chaining and verification issues.
You can configure the ESA in order to send an alert if the TLS negotiation fails when messages are delivered to a domain that requires a TLS connection. The alert message contains the name of the destination domain for the failed TLS negotiation. The ESA sends the alert message to all of the recipients that are set to receive warning severity level alerts for System alert types.
Note: This is a global setting, so it cannot be set on a per-domain basis.
Complete these steps in order to enable TLS connection alerts:
Tip: You can also configure this setting with the destconfig > setup CLI command.
The ESA also logs the instances for which TLS is required for a domain, but could not be used in the appliance mail logs. This occurs when any of these conditions are met:
The TLS connections are recorded in the mail logs, along with other significant actions that are related to messages, such as filter actions, anti-virus and anti-spam verdicts, and delivery attempts. If there is a successful TLS connection, there is a resulting TLS success entry in the mail logs. Likewise, a failed TLS connection produces a TLS failed entry. If a message does not have an associated TLS entry in the log file, that message was not delivered over a TLS connection.
Tip: In order to understand the mail logs, refer to the ESA Message Disposition Determination Cisco document.
Here is an example of a successful TLS connection from the remote host (reception):
Tue Apr 17 00:57:53 2018 Info: New SMTP ICID 590125205 interface Data 1 (192.168.1.1) address 10.0.0.1 reverse dns host mail.example.com verified yes
Tue Apr 17 00:57:53 2018 Info: ICID 590125205 ACCEPT SG SUSPECTLIST match sbrs[-1.4:2.0] SBRS -1.1
Tue Apr 17 00:57:54 2018 Info: ICID 590125205 TLS success protocol TLSv1 cipher DHE-RSA-AES256-SHA
Tue Apr 17 00:57:55 2018 Info: Start MID 179701980 ICID 590125205
Here is an example of a failed TLS connection from the remote host (reception):
Mon Apr 16 18:59:13 2018 Info: New SMTP ICID 590052584 interface Data 1 (192.168.1.1) address 10.0.0.1 reverse dns host mail.example.com verified yes
Mon Apr 16 18:59:13 2018 Info: ICID 590052584 ACCEPT SG UNKNOWNLIST match sbrs[2.1:10.0] SBRS 2.7
Mon Apr 16 18:59:14 2018 Info: ICID 590052584 TLS failed: (336109761, 'error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher')
Mon Apr 16 18:59:14 2018 Info: ICID 590052584 lost
Mon Apr 16 18:59:14 2018 Info: ICID 590052584 close
Here is an example of a successful TLS connection to the remote host (delivery):
Tue Apr 17 00:58:02 2018 Info: New SMTP DCID 41014367 interface 192.168.1.1 address 10.0.0.1 port 25
Tue Apr 17 00:58:02 2018 Info: DCID 41014367 TLS success protocol TLSv1.2 cipher ECDHE-RSA-AES256-GCM-SHA384
Tue Apr 17 00:58:03 2018 Info: Delivery start DCID 41014367 MID 179701982 to RID [0]
Here is an example of a failed TLS connection to the remote host (delivery):
Mon Apr 16 00:01:34 2018 Info: New SMTP DCID 40986669 interface 192.168.1.1 address 10.0.0.1 port 25
Mon Apr 16 00:01:35 2018 Info: Connection Error: DCID 40986669 domain: domain IP:10.0.0.1 port: 25 details: 454-'TLS not available due to
temporary reason' interface: 192.168.1.1 reason: unexpected SMTP response
Mon Apr 16 00:01:35 2018 Info: DCID 40986669 TLS failed: STARTTLS unexpected response
Revision | Publish Date | Comments |
---|---|---|
3.0 |
29-Mar-2024 |
Recertification |
1.0 |
05-Aug-2015 |
Initial Release |