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