reason: 403 4.7.0 TLS handshake failed

Question

Sending email to one particular domain, I get the following error:

   ----- The following addresses had permanent fatal errors -----
<>
    (reason: 403 4.7.0 TLS handshake failed.)

   ----- Transcript of session follows -----
<>... Deferred

Wondering if this is an issue with my mail server, or the recipient...

So this is happening on two domains now... both of whome are using outlook.com as mail providers:

openssl s_client -starttls smtp -connect x-com.mail.eo.outlook.com:25

CONNECTED(00000003) depth=2 CN = Microsoft Internet Authority verify error:num=20:unable to get local issuer certificate verify return:0
--- Certificate chain  0 s:/C=US/ST=WA/L=Redmond/O=Microsoft/OU=Forefront Online Protection for Exchange/CN=mail.protection.outlook.com    i:/DC=com/DC=microsoft/DC=corp/DC=redmond/CN=MSIT Machine Auth CA 2  1 s:/DC=com/DC=microsoft/DC=corp/DC=redmond/CN=MSIT Machine Auth CA 2    i:/CN=Microsoft Internet Authority  2 s:/CN=Microsoft Internet Authority    i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
--- Server certificate
-----BEGIN CERTIFICATE----- MIIHITCCBgmgAwIBAgIKaJVJ8AABAADfvjANBgkqhkiG9w0BAQUFADCBgDETMBEG CgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEUMBIG CgmSJomT8ixkARkWBGNvcnAxFzAVBgoJkiaJk/IsZAEZFgdyZWRtb25kMR8wHQYD VQQDExZNU0lUIE1hY2hpbmUgQXV0aCBDQSAyMB4XDTE0MDUyOTIyMTk0NloXDTE2 MDUxNTIwNTA1NVowgZkxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQMA4GA1UE BxMHUmVkbW9uZDESMBAGA1UEChMJTWljcm9zb2Z0MTEwLwYDVQQLEyhGb3JlZnJv bnQgT25saW5lIFByb3RlY3Rpb24gZm9yIEV4Y2hhbmdlMSQwIgYDVQQDExttYWls LnByb3RlY3Rpb24ub3V0bG9vay5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQC//+TcN6C92y7BZE4E9+3VJfxW/QHCbOdk8/W2rZ9NXK+JfgM8t6lD
+Xi9IQflxEnOpuANelypefk5rfpJuiSnGRGMg44xAWQkhhBVynduvDRoddd9ieaC LIC0rcuyeqpvXnw8MPZdp1nRn12XoOrDhUYBke3JRk9JKys5yOec+g5a65nUxp++ jDtQOHCN60n5MmGZH5a+/EX++ZpyC13SISHEcVLNRDMMHzpmYT3h5JjCe3AhMgTy qbjavIddv5lAyuGw9UsSpmjdyQ0gLPepfKscZ/5bp6QRT8rOj3d4jTlAbqsjJM6y PBHxAHXrLiCPC3mn38Eggs7PIAPce47/AgMBAAGjggOAMIIDfDALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMHgGCSqGSIb3DQEJDwRr MGkwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDALBglghkgBZQMEASow CwYJYIZIAWUDBAEtMAsGCWCGSAFlAwQBAjALBglghkgBZQMEAQUwBwYFKw4DAgcw CgYIKoZIhvcNAwcwHQYDVR0OBBYEFOdAD77qj+T7cfw6+hwbEjOKBl9DMB8GA1Ud IwQYMBaAFOvbEV74CZ7Y1mKc/WKd44RKKOEnMIHuBgNVHR8EgeYwgeMwgeCggd2g gdqGT2h0dHA6Ly9tc2NybC5taWNyb3NvZnQuY29tL3BraS9tc2NvcnAvY3JsL01T SVQlMjBNYWNoaW5lJTIwQXV0aCUyMENBJTIwMigxKS5jcmyGTWh0dHA6Ly9jcmwu bWljcm9zb2Z0LmNvbS9wa2kvbXNjb3JwL2NybC9NU0lUJTIwTWFjaGluZSUyMEF1 dGglMjBDQSUyMDIoMSkuY3JshjhodHRwOi8vY29ycHBraS9jcmwvTVNJVCUyME1h Y2hpbmUlMjBBdXRoJTIwQ0ElMjAyKDEpLmNybDCBrQYIKwYBBQUHAQEEgaAwgZ0w VQYIKwYBBQUHMAKGSWh0dHA6Ly93d3cubWljcm9zb2Z0LmNvbS9wa2kvbXNjb3Jw L01TSVQlMjBNYWNoaW5lJTIwQXV0aCUyMENBJTIwMigxKS5jcnQwRAYIKwYBBQUH MAKGOGh0dHA6Ly9jb3JwcGtpL2FpYS9NU0lUJTIwTWFjaGluZSUyMEF1dGglMjBD QSUyMDIoMSkuY3J0MD8GCSsGAQQBgjcVBwQyMDAGKCsGAQQBgjcVCIPPiU2t8gKF oZ8MgvrKfYHh+3SBT4PC7YUIjqnShWMCAWQCAQ0wJwYJKwYBBAGCNxUKBBowGDAK BggrBgEFBQcDAjAKBggrBgEFBQcDATCBiAYDVR0RBIGAMH6CFSoubWFpbC5lby5v dXRsb29rLmNvbYIdKi5tYWlsLnByb3RlY3Rpb24ub3V0bG9vay5jb22CG21haWwu cHJvdGVjdGlvbi5vdXRsb29rLmNvbYILb3V0bG9vay5jb22CHG1haWwubWVzc2Fn aW5nLm1pY3Jvc29mdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAG0IKQDUPEOjAOv2 RMUAzyveNL590cdIVRNb3qq9kOOAK2HsUJJy8AE6HXEhgAl2kOyeIUKLlO0iYVRe Viapc0nAcmuGT0AJtNEOaklBBzEAxfMBVsDuo1N9ngGDH4sx0izkM1R6fkN6fjHe lVWeyne4GnJG//RoiQDIoRcETgLhpr+fd972PupvF13ao+tC3L4MEx6K5KfDY4z9 Fvjz+uPd1Y/6h2PwmxyBR2C5G2hkAsKs7ZD2ZhI5JhI+Sle4JLFDcjhdYVHS/dGo s5+lCADuoG4gaPkdHplaqHyF5p8kREhlCOlwhEp3c6LXoTjgG75Lu02V1YKy+DZK v5STRJE=
-----END CERTIFICATE----- subject=/C=US/ST=WA/L=Redmond/O=Microsoft/OU=Forefront Online Protection for Exchange/CN=mail.protection.outlook.com issuer=/DC=com/DC=microsoft/DC=corp/DC=redmond/CN=MSIT Machine Auth CA 2
--- Acceptable client certificate CA names /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority /O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048) /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network /C=US/O=SecureTrust Corporation/CN=SecureTrust CA /C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root /C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Secure Server Certification Authority /C=CH/O=SwissSign AG/CN=SwissSign Silver CA - G2 /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA /C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA /C=US/O=Entrust, Inc./OU=www.entrust.net/CPS is incorporated by reference/OU=(c) 2006 Entrust, Inc./CN=Entrust Root Certification Authority /C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Root Certificate Authority - G2 /C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2 /C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root /C=CH/O=SwissSign AG/CN=SwissSign Gold CA - G2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Root Certificate Authority 2010 /OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority /DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority /CN=NT AUTHORITY
--- SSL handshake has read 8738 bytes and written 566 bytes
--- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-SHA384
    Session-ID: 991B0000D75A2D35BA784D9139460FCC0234D206A71677CE0D40B92CF8698C7C
    Session-ID-ctx:
    Master-Key: 5C84C017A9B2B9E0DF1B9E7E7A14BDF6666B02A4281D5ADF352BF6AEDDFE31D826E394B4DB4F4B72357E45CAF402A4CE
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1424906131
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
--- 250 CHUNKING

What's the recipient domain? – masegaloeh Feb 15 '15 at 01:00 — masegaloeh, Feb 15 '15 at 01:00

score 4 · Answer 1 · answered Feb 14 '15 at 23:15

4

There is likely a mismatch between the ciphers that are supported by your server, and those supported by the recipient's server.

On a given connection, once the initiating server attempts to STARTTLS, there's no going back. (It doesn't have to necessarily attempt STARTTLS, but once it does, the state of the connection is forever altered.)

If the mismatch of the ciphers occurs, then the connection cannot proceed, and, as per above, there's no going back to pre-TLS state, so, you just have to abandon the connection, and retry.

Supposedly, proper software is supposed to retry without STARTTLS in such situations, according to most of the specs of these protocols that support a StartTLS extension, but it's not entirely clear whether most software implements such retries or not.

answered Feb 14 '15 at 23:15

cnst

12,948
7
51
75

So is it something that I can fix on my end or is it something on theirs? Just curious because although this only happens to this domain, I'd rather fix it on mine if I can. – NinjaCat Feb 15 '15 at 00:51
@NinjaCat, You could try upgrading or downgrading your OpenSSL / Java / etc. You could try to disable client-mode STARTTLS. – cnst Feb 15 '15 at 00:54
What are the cons for disabling client-mode starttls? – NinjaCat Feb 15 '15 at 06:48
@NinjaCat, if you disable client-mode starttls, then the outgoing connections from your server to the other servers won't be opportunistically encrypted for email traffic, e.g. emails you sent won't be protected from passive monitoring. some software also lets you disable/enable/enforce starttls on a per-domain basis, so, perhaps that's what you ultimately want here. – cnst Feb 16 '15 at 05:14
1

btw, what's up with the secrecy, what kind of mail servers you and your recipient are using that you're having these issues? – cnst Feb 16 '15 at 05:14
I edited the original post with more information. – NinjaCat Feb 25 '15 at 23:18

score 1 · Accepted Answer · answered Jun 11 '15 at 14:05

1

So it turns out that I had seen this with other servers with a common thread that all affected domains were using outlook. I looked into this more and found that my email cert had expired. I fixed that and all is well.

answered Jun 11 '15 at 14:05

NinjaCat

576
1
9
20

reason: 403 4.7.0 TLS handshake failed

2 Answers2

Linked