Why don't Google MX servers comply with SSL CN certificate?

Question

Before sending email to a google account, my script looked at MX records for Google mail servers. Results:

gmail-smtp-in.l.google.com alt1.gmail-smtp-in.l.google.com alt2.gmail-smtp-in.l.google.com alt3.gmail-smtp-in.l.google.com alt4.gmail-smtp-in.l.google.com 

Then I successfully connected to gmail-smtp-in.l.google.com , and after EHLO I launched a STARTTLS request to switch to SSL. However, I installed a script to check and verify that the hosts (hosts) listed in the certificate correspond to the domain , I also connected.

 stream_context_set_option($fh, 'ssl', 'CN_match', 'gmail-smtp-in.l.google.com`); 

However, this is where things break. I got the following error:

 stream_socket_enable_crypto(): Peer certificate CN='mx.google.com' did not match expected CN='gmail-smtp-in.l.google.com' 

I checked where nslookup mx.google.com is located and found that it does not exist.

 Server: 127.0.0.1 Address: 127.0.0.1#53 ** server can't find mx.google.com: NXDOMAIN 

Why does the SSL certificate not match the domain using it? Did I miss something?

Below is the certificate received by me script.

 Array ( [name] => /C=US/ST=California/L=Mountain View/O=Google Inc/CN=mx.google.com [subject] => Array ( [C] => US [ST] => California [L] => Mountain View [O] => Google Inc [CN] => mx.google.com ) [hash] => fbf7dda6 [issuer] => Array ( [C] => US [O] => Google Inc [CN] => Google Internet Authority ) [version] => 2 [serialNumber] => 280762463620984597407910 [validFrom] => 120912115656Z [validTo] => 130607194327Z [validFrom_time_t] => 1347451016 [validTo_time_t] => 1370634207 [purposes] => Array ( [1] => Array ( [0] => 1 [1] => [2] => sslclient ) [2] => Array ( [0] => 1 [1] => [2] => sslserver ) [3] => Array ( [0] => 1 [1] => [2] => nssslserver ) [4] => Array ( [0] => [1] => [2] => smimesign ) [5] => Array ( [0] => [1] => [2] => smimeencrypt ) [6] => Array ( [0] => 1 [1] => [2] => crlsign ) [7] => Array ( [0] => 1 [1] => 1 [2] => any ) [8] => Array ( [0] => 1 [1] => [2] => ocsphelper ) ) [extensions] => Array ( [extendedKeyUsage] => TLS Web Server Authentication, TLS Web Client Authentication [subjectKeyIdentifier] => 69:B3:67:5C:04:7F:16:EF:C1:85:FB:E8:2D:E4:FC:21:E9:7D:93:AF [authorityKeyIdentifier] => keyid:BF:C0:30:EB:F5:43:11:3E:67:BA:9E:91:FB:FC:6A:DA:E3:6B:12:24 [crlDistributionPoints] => URI:http://www.gstatic.com/GoogleInternetAuthority/GoogleInternetAuthority.crl [authorityInfoAccess] => CA Issuers - URI:http://www.gstatic.com/GoogleInternetAuthority/GoogleInternetAuthority.crt [basicConstraints] => CA:FALSE [subjectAltName] => DNS:mx.google.com ) ) 

Answer 1

There are two possible reasons for this.

• First, the SMTP hostname mapping has traditionally been determined rather vaguely. You can check out the historical notes about this in RFC 6125 (recent RFC on best practices for checking hostnames that are not yet widely used). RFC 3207 (Secure SMTP over Transport Layer Security) does not provide detailed information about where the host name should be in the certificate. RFC 4954 (an extension of the SMTP service for authentication) provides more detailed information and talks about alternative object names, but this is in the context of SASL. Ambiguous or vague host name matching specifications are often the reason why, unfortunately, no proper attempt is made to match a host name.

• Secondly, SSL / TLS is rarely used between Mail Transfer Agents (MTA) . What you do, getting an MX DNS record and trying to send an email directly to it, as a rule, does my MTA, not just the Mail Submission Agent .

  Typical use of SSL / TLS for SMTP occurs between the mail user agent (email client) and the mail sending agent (your Internet service provider's email server, where you must authenticate).

  SSL / TLS between MTAs is difficult to configure because not every server supports it, and it is difficult to know which MTAs will support it. Some people advocate support for upbeat TLS, whereby you are trying to figure out if the server you are talking to supports TLS and return to simple SMTP if it is not. Unfortunately, this is not enough, because you are clearly vulnerable to MITM attacks as soon as you want to lower the rating.

  In addition, the MX record you receive may itself be compromised (at least without DNSSEC).

  All in all, it's actually quite difficult to rely on any form of email transport security outside of the MUA / MSA connection. This probably explains why little attention is paid to properly configuring MX servers for SSL / TLS.