ietf-smtp
[Top] [All Lists]

SMTP TLS and CN Domain Matching

2011-11-14 23:24:28

Carl S. Gutekunst wrote:

Alexey Melnikov wrote:
Backward compatibility might be a sufficient reason to violate the SHOULD NOT.

I don't think it's that easy. The issue is with Email virtual hosting implementations that embed the virtual domain name (or any token with dots in it) in the MX record. For example, if you look up the MX record for gutekunst.org, you'll see:

   gutekunst.org.        86382    IN    MX    100
   gutekunst.org.s8a1.psmtp.com.
   gutekunst.org.        86382    IN    MX    200
   gutekunst.org.s8a2.psmtp.com.
   gutekunst.org.        86382    IN    MX    300
   gutekunst.org.s8b1.psmtp.com.
   gutekunst.org.        86382    IN    MX    400
   gutekunst.org.s8b2.psmtp.com.

Postini's SSL certificate reads:

   Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=*.psmtp.com

I'm sure they aren't the only ESP that does this; MXLogic for sure, probably CheckFree, possibly FrontBridge.

Very interesting. I can see this will need to be addressed in our server where, if enabled, the certificate is stored based on the CN name. Using our consoled-based SMTP testing client, here is the result:

* connecting to host: gutekunst.org.s8a1.psmtp.com ip: 64.18.7.10:25
S: 220 Postini ESMTP 296 y6_45_0c2 ready. CA Business and Professions Code Section 17538.45 forbids use of th
is system for unsolicited electronic mail advertisements.
C: EHLO main2.addom.santronics.com
S: 250-Postini says hello back
S: 250-STARTTLS
S: 250-8BITMIME
S: 250 HELP
C: STARTTLS
S: 220 Go ahead
** SSL Negotiated session
!! ERROR 123 - saving server's cert to *.psmtp.com.cert
** CERT Common Name : *.psmtp.com
** CERT Organization: Google Inc
** CERT Valid Until : May 25 00:34:28 2012 GMT (Days Left: 191)
** CA Country       : US
** CA Organiziation : Google Inc
** CA Common Name   : Google Internet Authority
!! connection domain : gutekunst.org.s8a1.psmtp.com
!! common name       : *.psmtp.com
!! Certificate CONNECTION DOMAIN and COMMON NAME mismatch! Accept? Yes or No?

The error is minor, of course, but I can see your point here. I did another run with a match check of the computer name (rDNS) and got this:

!! computer name     : s8a1.psmtp.com
!! common name       : *.psmtp.com
!! Certificate COMPUTER NAME and COMMON NAME mismatch. Accept? Yes or No?

I wonder how the current MUAs will work here. What have you see with the MUAs? like OE, Thunderbird and others?

To answer your question about interest,  here is what I think:

First, I think getting a baseline of who are the beneficiaries, is the client mandating correctness or if the server requiring a correct matching client certificate?

Second, finding out if wild cards is done in this fashion across the board. Is this how its done all CA do it? I think OCSP should be looked at as a possible optional solution or something that would be part of the validation suite:

RFC2560 X.509 IPKI Online Certificate Status Protocol, Updated by 6277
   RFC6277  Online Certificate Status Protocol Algorithm Agility
   RFC4806  Online Certificate Status Protocol (OCSP) Extensions to IKEv2

My experience here began with a very large national chain customer who paid the bucks for a wild card certificate and unbeknownst to them, there was some SSL purchasing mixup issue that the CA revoked had revoked it. But that didn't show up with the browsers (no SSL error) until some users with updated browsers which now had OCSP enabled began to show the insecure warning error "do you wish to continue" pages. That provided the clue that there was an SSL purchasing mix up with the group of domains they wanted signed by the CA. Turning off the OSCP at the browser got by it, but of course, thats not realistic to presume to be off with new browsers now enabling it.

and third, work out the "algorithm" for the matching options of the CN, possibly by first seeing the current practice by MUAs where there is an interactive HUMAN involved to help with the decisions. The end goal here is to see is automation is possible with two MTAs.

Keep in mind, at least for us where we have it setup on a per remote host setup where specific MTA connection details are provided for a target email domain or host, they could bypass the MX host. For example, I did the same test run for your domain:

* connecting to host: mail.gutekunst.org.s8a1.psmtp.com ip: 128.177.28.115:25
S: 220 alameth.user.openhosting.com ESMTP Postfix (2.4.1)
C: EHLO main2.addom.santronics.com
S: 250-alameth.user.openhosting.com
S: 250-PIPELINING
S: 250-SIZE 10240000
S: 250-VRFY
S: 250-ETRN
S: 250-STARTTLS
S: 250-ENHANCEDSTATUSCODES
S: 250-8BITMIME
S: 250 DSN
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
** SSL Negotiated session
** CERT Common Name : mail.gutekunst.org
** CERT Organization:
** CERT Valid Until : Nov 10 22:35:42 2012 GMT (Days Left: 361)
** CA Country       : IL
** CA Organiziation : StartCom Ltd.
** CA Common Name   : StartCom Class 1 Primary Intermediate Server CA
!! computer name     : 128-177-28-115.ip.openhosting.com
!! common name       : mail.gutekunst.org
!! Certificate COMPUTER NAME and COMMON NAME mismatch. Accept? Yes or No? n

So it passed the connection name test, and it would pass the computer name test if I disable the rDNS matching check.

Point here is I believe that when it comes to prearranged remote host routing, the authentication and TLS details may be already worked out for validation.

--
Sincerely

Hector Santos
http://www.santronics.com
jabber: hector(_at_)jabber(_dot_)isdg(_dot_)net

<Prev in Thread] Current Thread [Next in Thread>