Invalid or expired SS certificate of att.yahoo.com:995

Certificate message indicates domain validation error for 'legacy.pop.mail.yahoo.com'.  DNS record is as follows:

dig @8.8.8.8 legacy.pop.mail.yahoo.com

; <<>> DiG 9.10.4-P5-RedHat-9.10.4-4.P5.fc25 <<>> @8.8.8.8 legacy.pop.mail.yahoo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21934
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;legacy.pop.mail.yahoo.com. IN A

;; ANSWER SECTION:
legacy.pop.mail.yahoo.com. 58 IN CNAME pop.mail.yahoo.com.
pop.mail.yahoo.com. 66 IN CNAME global-jpop.mail.gm0.yahoodns.net.
global-jpop.mail.gm0.yahoodns.net. 66 IN A 98.138.122.37
global-jpop.mail.gm0.yahoodns.net. 66 IN A 74.6.105.39
global-jpop.mail.gm0.yahoodns.net. 66 IN A 216.155.194.54
global-jpop.mail.gm0.yahoodns.net. 66 IN A 74.6.106.14

;; Query time: 41 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Feb 15 12:06:38 EST 2017
;; MSG SIZE rcvd: 179

Looks like the same server IP addresses as 'inbound.att.net', I'm going to go ahead and add a permanent exception.

I'm still trying to learn about this certificate thingie. 🙂

I've been doing some reading at

https://support.f5.com/csp/article/K14819

I think some of it may be starting to sink in.

Here's a copy of an error log I receive

2/15/2017, 14:32:39: FETCH - receiving mail messages
2/15/2017, 14:32:39: FETCH - Connecting to POP3 server inbound.att.net on port 995
2/15/2017, 14:32:39: FETCH - Initiating TLS handshake
>2/15/2017, 14:32:39: FETCH - Certificate S/N: 0DCF4B142694EC75C8499B7CABDDB8FF, algorithm: RSA (2048 bits), issued from 9/20/2016 to 9/20/2018 11:59:59 PM, for 26 host(s): legacy.pop.mail.yahoo.com, pop.mail.yahoo.com, *.pop.mail.yahoo.com, pop.bizmail.yahoo.com, pop.mail.yahoo.com.ar, pop.mail.yahoo.com.au, pop.mail.yahoo.com.br, pop.mail.yahoo.com.hk, pop.mail.yahoo.com.my, pop.mail.yahoo.com.ph, pop.mail.yahoo.com.sg, pop.mail.yahoo.com.tw, pop.mail.yahoo.com.vn, pop.mail.yahoo.co.id, pop.mail.yahoo.co.in, pop.mail.yahoo.co.kr, pop.mail.yahoo.co.th, pop.mail.yahoo.co.uk, pop.mail.yahoo.ca, pop.mail.yahoo.de, pop.mail.yahoo.fr, pop.mail.yahoo.in, pop.mail.yahoo.it, pop.correo.yahoo.es, pop.y7mail.com, pop.att.yahoo.com.
>2/15/2017, 14:32:39: FETCH - Owner: "US", "California", "Sunnyvale", "Yahoo Inc.", "Information Technology", "legacy.pop.mail.yahoo.com".
>2/15/2017, 14:32:39: FETCH - Issuer: "US", "Symantec Corporation", "Symantec Trust Network", "Symantec Class 3 Secure Server CA - G4". Valid from 10/31/2013 to 10/30/2023 11:59:59 PM.
>2/15/2017, 14:32:39: FETCH - Root: "US", "VeriSign, Inc.", "VeriSign Trust Network", "(c) 2006 VeriSign, Inc. - For authorized use only", "VeriSign Class 3 Public Primary Certification Authority - G5". Valid from 11/8/2006 to 7/16/2036 11:59:59 PM.
!2/15/2017, 14:32:39: FETCH - TLS handshake failure. The server host name ("inbound.att.net") does not match the certificate.

above,

after the line -

>2/15/2017, 14:32:39: FETCH - Certificate S/N:...

I do not see inbound.att.net listed within the cert.

Is this where the problem is?

My email client support tells me:

You get this error message (FETCH - TLS handshake failure. The server host name ("inbound.att.net") does not match the certificate.) because the server certificate does not contain the server address you connect to - "inbound.att.net".
In this case to make the connection secure you need to import the root certificate into the certificate database. To accomplish that read the following instructions:

1. Contact the server administrator and ask him/her to provide you with the certificate. Once received, save that file to your local HDD.

2. Open the address book in The Bat! and make sure "View/Certificate Address Books" is enabled.
3. Select the Trusted Root CA address book and create a new contact there.
4. Open the properties of that contact and go to the "Certificates" tab.
5. Import the certificate you had received.

So how to I get an att server administrator to provide me with a certificate that includes the address inbound.att.net  that is on the server that my email client connects too?

Or is this not the problem?

Meanwhile I'm stiiiil thinking. 🙂

I'm still trying to learn about this certificate thingie.
I've been doing some reading at
https://support.f5.com/csp/article/K14819
I think some of it may be starting to sink in.
Here's a copy of an error log I receive

2/15/2017, 14:32:39: FETCH - receiving mail messages
2/15/2017, 14:32:39: FETCH - Connecting to POP3 server inbound.att.net on port 995
2/15/2017, 14:32:39: FETCH - Initiating TLS handshake
>2/15/2017, 14:32:39: FETCH - Certificate S/N: 0DCF4B142694EC75C8499B7CABDDB8FF, algorithm: RSA (2048 bits), issued from 9/20/2016 to 9/20/2018 11:59:59 PM, for 26 host(s): legacy.pop.mail.yahoo.com, pop.mail.yahoo.com, *.pop.mail.yahoo.com, pop.bizmail.yahoo.com, pop.mail.yahoo.com.ar, pop.mail.yahoo.com.au, pop.mail.yahoo.com.br, pop.mail.yahoo.com.hk, pop.mail.yahoo.com.my, pop.mail.yahoo.com.ph, pop.mail.yahoo.com.sg, pop.mail.yahoo.com.tw, pop.mail.yahoo.com.vn, pop.mail.yahoo.co.id, pop.mail.yahoo.co.in, pop.mail.yahoo.co.kr, pop.mail.yahoo.co.th, pop.mail.yahoo.co.uk, pop.mail.yahoo.ca, pop.mail.yahoo.de, pop.mail.yahoo.fr, pop.mail.yahoo.in, pop.mail.yahoo.it, pop.correo.yahoo.es, pop.y7mail.com, pop.att.yahoo.com.
>2/15/2017, 14:32:39: FETCH - Owner: "US", "California", "Sunnyvale", "Yahoo Inc.", "Information Technology", "legacy.pop.mail.yahoo.com".
>2/15/2017, 14:32:39: FETCH - Issuer: "US", "Symantec Corporation", "Symantec Trust Network", "Symantec Class 3 Secure Server CA - G4". Valid from 10/31/2013 to 10/30/2023 11:59:59 PM.
>2/15/2017, 14:32:39: FETCH - Root: "US", "VeriSign, Inc.", "VeriSign Trust Network", "(c) 2006 VeriSign, Inc. - For authorized use only", "VeriSign Class 3 Public Primary Certification Authority - G5". Valid from 11/8/2006 to 7/16/2036 11:59:59 PM.
!2/15/2017, 14:32:39: FETCH - TLS handshake failure. The server host name ("inbound.att.net") does not match the certificate.

above,
after the line -
>2/15/2017, 14:32:39: FETCH - Certificate S/N:...
I do not see inbound.att.net listed within the cert.
Is this where the problem is?

My email client support tells me:
You get this error message (FETCH - TLS handshake failure. The server host name ("inbound.att.net") does not match the certificate.) because the server certificate does not contain the server address you connect to - "inbound.att.net".
In this case to make the connection secure you need to import the root certificate into the certificate database. To accomplish that read the following instructions:

1. Contact the server administrator and ask him/her to provide you with the certificate. Once received, save that file to your local HDD.
2. Open the address book in The Bat! and make sure "View/Certificate Address Books" is enabled.
3. Select the Trusted Root CA address book and create a new contact there.
4. Open the properties of that contact and go to the "Certificates" tab.
5. Import the certificate you had received.

So how do I get an att server administrator to provide me with a certificate that includes the address inbound.att.net that is on the server that my email client connects too?

Or is this not the problem?
Meanwhile I'm stiiiil thinking.

Hi,

You should be able to get a certificate automatically when connecting. Sometimes it does not update, so we suggest deleting the current certificate so it can get a new one. You can try using a different E-mail client and see if it works. If so, then it may just be an issue with the E-mail client program working with AT&T servers.

-ATTU-verseCare

This error turned out to be a blessing in disguise.  From it I found out that AT&T U-verse now has IMAP mail servers, so I backed up my mail, disabled the POP accounts, and added new IMAP ones.  Sure enough, all my mail download, and I was able to salvage older mail from the POP accounts before deleting them.  So problem fixed, and now my Read flags sync across all my devices.

The email server miraculously comes back to normal.   I did not actually do anything but re-input excact the same setting.  

Not sure if the email server pop.att.yahoo.com fixed itself or unknowingly did something that fixed.

I hope it will continue work, otherwise I will try using inbound.att.net for incoming and outbound.att.net for outgoing.

Thank you everybody.

Stephen

 So I am able to use my client again! Just had to change setting back to pop.mail.yahoo.com 

The link that is in posted above (https://www.att.com/support/article/dsl-high-speed/KM1010523) points to a page for "Verify your email client server setting"s and on that page suggests to set your Inbound server / port - Mail server settings for att.net or bellsouth.net to POP3 inbound.att.net / 995.

It seems that the att server that my computer contacts, when I have my email client server settings set to POP3 inbound.att.net / 995 finds a misconfiguration in regards to their certificate there by forcing my email client to respond with "TLS handshake failure. The server host name ("inbound.att.net") does not match the certificate."

but when I go against att's recommended settings and set my receive mail transport protocol or Mail server settings as it is called to pop.mail.yahoo.com I am now able to receive mail.

so I think if att finds the server with the misconfiguration and gets the server host name ("inbound.att.net") to match the certificate

then customers will nolonger have this trouble.

Just a guess

thank all of you for trying

So I am able to use my client again! Just had to change setting back to pop.mail.yahoo.com 
 
The link that is in posted above (https://www.att.com/esupport/article.html#!/dsl-high-speed/KM1010523) points to a page for "Verify your email client server setting"s and on that page suggests to set your Inbound server / port - Mail server settings for att.net or bellsouth.net to POP3 inbound.att.net / 995.
It seems that the att server that my computer contacts, when I have my email client server settings set to POP3 inbound.att.net / 995 finds a misconfiguration in regards to their certificate there by forcing my email client to respond with "TLS handshake failure. The server host name ("inbound.att.net") does not match the certificate."
but when I go against att's recommended settings and set my receive mail transport protocol or Mail server settings as it is called to pop.mail.yahoo.com I am now able to receive mail.
 
so I think if att finds the server with the misconfiguration and gets the server host name ("inbound.att.net") to match the certificate
then customers will nolonger have this trouble.
 
 
Just a guess
 
thank all of you for trying

---

@Mauwkie wrote:

 

...

so I think if att finds the server with the misconfiguration and gets the server host name ("inbound.att.net") to match the certificate

then customers will nolonger have this trouble....

 

 

---

@ATTU-verseCare, it certainly does seem like there is either a misconfigured Yahoo router in there or a bad DNS translation sending users to the wrong router making AT&T customers unhappy.  Can we put some pressure on them to get this fixed?