03-26-2013 07:09 PM
Obviously, this means that a TLS connection with certificate is required, and that the certificate should not have expired.
However, does it also check the certificate name? If so, against what?
I've a problem because a 'Required,verify' is failing to verify when routing to pfizer.com despite their appearing to produce a valid certificate.
The certificate provided by their MX server has a different CN from the MX hostname; however, the MX hostname IS in the AltNames.
RFC2818 ( http://tools.ietf.org/rfc/rfc2818.txt ) states in section 3.2 that the MX hostname MUST be compared against the AltNames if available, else against the CN.
However, from the tests I've done here, it seems that the MX hostname is only compared against the CN, and the AltNames are ignored. Is this the case? If so, then it is a bug.
Thanks,
-Steve
Details -
pfizer.com DNS
pfizer.com mail exchanger = 10 mxa-00013f02.gslb.pphosted.com.
pfizer.com mail exchanger = 10 mxb-00013f02.gslb.pphosted.com.
pfizer.com TLS certificate:
Subject: C=US, ST=California, L=Sunnyvale, O=Proofpoint, Inc., OU=Proofpoint OnDemand, CN=00013f02.pphosted.com
X509v3 Subject Alternative Name:
DNS:mxa-00013f02.gslb.pphosted.com, DNS:mxb-00013f02.gslb.pphosted.com, DNS:00013f02.pphosted.com
03-26-2013 08:30 PM
In other words, this is asking if the Ironport supports SSLv3 extensions when testing certificate validity.
03-30-2013 02:20 AM
Hello Steve,
AltNames are supported, but only for the destination domain name. This is described in Article #1412: "How does the IronPort Appliance perform the TLS certificate verification"
If the certificate has a subjectAltName extension with DNS names, compare these names against the destination domain name. This check supports wildcard matching.
Check if "example.com == subjectAltName"
The method you are referring to is the exact match to the MX name:
Example:
subjectAltName:dNSName=mx1.potassium.com
subjectAltName:dNSName=mx2.potassium.com
That is NOT supported by ESA , because there is no way to know if the MX records returned by DNS can be trusted. However, what's working to verify the certificate is the fact that the certificate chain verifies succesfully at the time of the TLS handshake.
Hope that helps,
Andreas
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide