About option "Verify Client Certificate" in Mail flow Policy

[REJR77]

Hi,

Just want a clarification on the option "Verify Client certificate" under TLS / Preferred (or Required).

When I choose Prefered and Verify Client certificate, what is done is the background?

I understand that the ESA acts as a server when receiving a connection from a remote MTA (client), so it has nothing to verify the client certificate...

Does it mean that the ESA connects back to the remote MTA and check its "server" certificate?

And what is checked? Signed by Trusted CA, Date and CN?

Thanks for the help

[Ken Stieers]

(Assuming you're looking at Destination Controls) Yes. When they ESA connects to another MTA, and you have it set to *** - Verify, the ESA checks to make sure that the cert matches the system it connects to, that the cert is still valid, and that the trust chain is valid.
Taken from the online help (https:///help/esa_help/index.html#!c_enabling_tls_and_certificate_verification_on_delivery.html#con_1126500)
For Preferred (Verify)

TLS is negotiated from the email gateway to the MTA(s) for the domain. The email gateway attempts to verify the domain's certificate.

Three outcomes are possible:

* TLS is negotiated and the certificate is verified. The mail is delivered via an encrypted session.
* TLS is negotiated, but the certificate is not verified. The mail is delivered via an encrypted session.
* No TLS connection is made and, subsequently the certificate is not verified. The email message is delivered in plain text.
For Required (Verify)

TLS is negotiated from the email gateway to the MTA(s) for the domain. Verification of the domain certificate is required. The following outcomes are possible:

* A TLS connection is negotiated and the certificate is verified. The email message is delivered via an encrypted session.
* A TLS connection is negotiated, but the certificate is not verified by a trusted Cerfificate Authority (CA). The mail is not delivered.
* A TLS connection is not negotiated. The mail is not delivered.

[REJR77]

Hi Ken,

Actually I was thinking off TLS settings in the Mail Flow Policy (not in destination controls).

You can choose, Prefered, Required and there is a "Verifiy Client certificate" option

But don't understand how it works in this situation since the ESA acts as a server in this case..

[Ken Stieers · Accepted solution]

When users are using a mail client to connect to send mail to the ESA, you can make them send a cert you can verify. So Thunderbird or Outlook or whatever has to have a cert that's valid. Its not clear what valid means in this case, but probably matching the sender address.
>From the online help again:

Deny, Prefer, or Require Transport Layer Security (TLS) in SMTP conversations for this listener.

If you select Preferred, you can make TLS mandatory for envelope senders from a specific domain or with a specific email address by selecting an Address List that specifies those domains and email addresses. When an envelope sender matching a domain or address in this list tries to send a message over a connection that does not use TLS, the email gateway rejects the connection and the sender will have to try again using TLS.

The Verify Client Certificate option directs the email gateway to establish a TLS connection to the user's mail application if the client certificate is valid. If you select this option for the TLS Preferred setting, the email gateway still allows a non-TLS connection if the user doesn't have a certificate, but rejects a connection if the user has an invalid certificate. For the TLS Required setting, selecting this option requires the user to have a valid certificate in order for the email gateway to allow the connection.

[REJR77]

So this means it is not possible to check the remote MTA certificate when it connects to the ESA?

[Ken Stieers]

Think of a remote MTA connecting more like a browser connecting to a web server.

Your browser doesn't send a cert unless you're logging into a page, which is actually separate from the HTTPS conversion...