Menu
▾
▴
fetchmail-users
|
From: Joe Acquisto-j. <jo...@j4...> - 2020-12-02 21:15:54
|
fetchmail: 6.3.26 Now gettting this error: fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed fetchmail: mail.xxxhost.com: SSL connection failed. fetchmail: socket error while fetching from in...@jb...@mail.xxxhost.com fetchmail: Query status=2 (SOCKET) Cert on my end appears valid. joe a. |
|
From: Matthias A. <mat...@gm...> - 2020-12-02 22:11:34
|
Am 02.12.20 um 22:02 schrieb Joe Acquisto-j4: > fetchmail: 6.3.26 Now gettting this error: > > fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed > fetchmail: mail.xxxhost.com: SSL connection failed. > fetchmail: socket error while fetching from in...@jb...@mail.xxxhost.com > fetchmail: Query status=2 (SOCKET) > > Cert on my end appears valid. Hi Joe, you may have noticed that the current version is now 6.4.14, and 6.4.X brought several SSL/TLS and logging fixes. 6.3.26 is some seven years old now, and I don't support it any longer. If you still see the same issues with a halfway recent 6.4.X release (I'm not too picky), please provide the information listed as needed in https://www.fetchmail.info/fetchmail-FAQ.html#G3 and share it, and please don't make up the server's name so we can actually use gnutls-cli or openssl or similar tools to look at the server. What distribution and version are you running fetchmail on? What is your OpenSSL version that fetchmail links against? Regards Matthias |
|
From: Matthias A. <mat...@gm...> - 2020-12-02 22:24:05
|
Am 02.12.20 um 22:02 schrieb Joe Acquisto-j4: > fetchmail: 6.3.26 Now gettting this error: > > fetchmail: OpenSSL reported: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed > fetchmail: mail.xxxhost.com: SSL connection failed. > fetchmail: socket error while fetching from in...@jb...@mail.xxxhost.com > fetchmail: Query status=2 (SOCKET) > > Cert on my end appears valid. Oh, and in case mail.xxxhost.com is the true name, I offer my apologies for assuming it were made up, then the operator of mail.xxxhost.com needs to fix the certificate and/or configuration, or you need to configure to poll from an alternative hostname that is vacares.com or ends in .vacares.com. Running a recent fetchmail reveals it's a server-side configuration error: > $ FETCHMAILHOME=/tmp VCS-mine/fetchmail-64.git/_build-asan/fetchmail > --user johndoe mail.xxxhost.com --ssl -ppop3 --auth external > fetchmail: Server CommonName mismatch: *.vacares.com != mail.xxxhost.com > fetchmail: Server certificate verification error: Hostname mismatch > fetchmail: OpenSSL reported: error:1416F086:SSL > routines:tls_process_server_certificate:certificate verify failed > fetchmail: mail.xxxhost.com: SSL connection failed. > fetchmail: socket error while fetching from jo...@ma... > fetchmail: Query status=2 (SOCKET) Adding -v to fetchmail's command line (verbose mode) reveals some more (you could add a second -v, not shown here, left as an exercise for the reader): > $ FETCHMAILHOME=/tmp VCS-mine/fetchmail-64.git/_build-asan/fetchmail > -v --user johndoe mail.xxxhost.com --ssl -ppop3 --auth external > fetchmail: 6.4.14 querying mail.xxxhost.com (protocol POP3) at Mi 02 > Dez 2020 23:18:39 CET: poll started > Trying to connect to 84.247.2.168/995...connected. > fetchmail: Server certificate: > fetchmail: Issuer Organization: Sectigo Limited > fetchmail: Issuer CommonName: Sectigo RSA Domain Validation Secure > Server CA > fetchmail: Subject CommonName: *.vacares.com > fetchmail: Subject Alternative Name: *.vacares.com > fetchmail: Subject Alternative Name: vacares.com > fetchmail: Server CommonName mismatch: *.vacares.com != mail.xxxhost.com > fetchmail: mail.xxxhost.com key fingerprint: > 96:0F:21:78:99:7C:29:98:A6:2B:1F:B8:8D:51:4A:68 > fetchmail: Server certificate verification error: Hostname mismatch > fetchmail: OpenSSL reported: error:1416F086:SSL > routines:tls_process_server_certificate:certificate verify failed > fetchmail: mail.xxxhost.com: SSL connection failed. > fetchmail: socket error while fetching from jo...@ma... > fetchmail: 6.4.14 querying mail.xxxhost.com (protocol POP3) at Mi 02 > Dez 2020 23:18:39 CET: poll completed > fetchmail: Query status=2 (SOCKET) > fetchmail: normal termination, status 2 Similar outcome with gnutls-cli (see Status near the end): > $ gnutls-cli -p 993 mail.xxxhost.com > Processed 147 CA certificate(s). > Resolving 'mail.xxxhost.com:993'... > Connecting to '84.247.2.168:993'... > - Certificate type: X.509 > - Got a certificate list of 4 certificates. > - Certificate[0] info: > - subject `CN=*.vacares.com', issuer `CN=Sectigo RSA Domain > Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater > Manchester,C=GB', serial 0x008dfe7795c6d801c5326f05a13b5c3e2a, RSA key > 4096 bits, signed using RSA-SHA256, activated `2020-06-05 00:00:00 > UTC', expires `2021-06-05 23:59:59 UTC', > pin-sha256="MfW9RHMXODSXNfNRy0f4k8v253Lb/ySWrSo3wfzDTkg=" > Public Key ID: > sha1:28e3271a15a526f38e813f7cff6a9164e34cfb46 > > sha256:31f5bd44731738349735f351cb47f893cbf6e772dbff2496ad2a37c1fcc34e48 > Public Key PIN: > pin-sha256:MfW9RHMXODSXNfNRy0f4k8v253Lb/ySWrSo3wfzDTkg= > > - Certificate[1] info: > - subject `CN=Sectigo RSA Domain Validation Secure Server > CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB', issuer > `CN=USERTrust RSA Certification Authority,O=The USERTRUST > Network,L=Jersey City,ST=New Jersey,C=US', serial > 0x7d5b5126b476ba11db74160bbc530da7, RSA key 2048 bits, signed using > RSA-SHA384, activated `2018-11-02 00:00:00 UTC', expires `2030-12-31 > 23:59:59 UTC', pin-sha256="4a6cPehI7OG6cuDZka5NDZ7FR8a60d3auda+sKfg4Ng=" > - Certificate[2] info: > - subject `CN=USERTrust RSA Certification Authority,O=The USERTRUST > Network,L=Jersey City,ST=New Jersey,C=US', issuer `CN=AAA Certificate > Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB', > serial 0x3972443af922b751d7d36c10dd313595, RSA key 4096 bits, signed > using RSA-SHA384, activated `2019-03-12 00:00:00 UTC', expires > `2028-12-31 23:59:59 UTC', > pin-sha256="x4QzPSC810K5/cMjb05Qm4k3Bw5zBn4lTdO/nEW/Td4=" > - Certificate[3] info: > - subject `CN=AAA Certificate Services,O=Comodo CA > Limited,L=Salford,ST=Greater Manchester,C=GB', issuer `CN=AAA > Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater > Manchester,C=GB', serial 0x01, RSA key 2048 bits, signed using > RSA-SHA1, activated `2004-01-01 00:00:00 UTC', expires `2028-12-31 > 23:59:59 UTC', pin-sha256="vRU+17BDT2iGsXvOi76E7TQMcTLXAqj0+jGPdW7L1vM=" > - Status: The certificate is NOT trusted. The name in the certificate > does not match the expected. > *** PKI verification of server certificate failed... > *** Fatal error: Error in the certificate. HTH Matthias |
|
From: Joe Acquisto-j. <jo...@j4...> - 2020-12-02 22:57:42
|
> Am 02.12.20 um 22:02 schrieb Joe Acquisto-j4: >> fetchmail: 6.3.26 Now gettting this error: >> >> fetchmail: OpenSSL reported: error:1416F086:SSL > routines:tls_process_server_certificate:certificate verify failed >> fetchmail: mail.xxxhost.com: SSL connection failed. >> fetchmail: socket error while fetching from in...@jb...@mail.xxxhost.com >> fetchmail: Query status=2 (SOCKET) >> >> Cert on my end appears valid. > > Oh, and in case mail.xxxhost.com is the true name, I offer my apologies > for assuming it were made up, then the operator of mail.xxxhost.com > needs to fix the certificate and/or configuration, or you need to > configure to poll from an alternative hostname that is vacares.com or > ends in .vacares.com. > >. . . It was an obfuscated name, out of habit. gnutls seems to like the cert, though it would not connect on 993, resorted to 443. I can post the output if you think it of any value. It appears to be an intermittent problem, I suspect maybe the other end is doing some load sharing or updating. In any event I will try to update soon as I can. Thanks for the assistance. joe a. |
|
From: Matthias A. <mat...@gm...> - 2020-12-03 00:17:12
|
Am 02.12.20 um 23:57 schrieb Joe Acquisto-j4: >> Am 02.12.20 um 22:02 schrieb Joe Acquisto-j4: >>> fetchmail: 6.3.26 Now gettting this error: >>> >>> fetchmail: OpenSSL reported: error:1416F086:SSL >> routines:tls_process_server_certificate:certificate verify failed >>> fetchmail: mail.xxxhost.com: SSL connection failed. >>> fetchmail: socket error while fetching from in...@jb...@mail.xxxhost.com >>> fetchmail: Query status=2 (SOCKET) >>> >>> Cert on my end appears valid. >> Oh, and in case mail.xxxhost.com is the true name, I offer my apologies >> for assuming it were made up, then the operator of mail.xxxhost.com >> needs to fix the certificate and/or configuration, or you need to >> configure to poll from an alternative hostname that is vacares.com or >> ends in .vacares.com. >> >> . . . > It was an obfuscated name, out of habit. > > gnutls seems to like the cert, though it would not connect on 993, resorted to 443. Well, 993 is for IMAP under TLS wrapper, and 995 for POP3 under TLS wrapper, or you tell that tool to do starttls and use 110 (POP3) or 143 (IMAP). Resorting to HTTP may or may not work - there may be transparent proxies, different certificate configuration for web vs. mail service, so the results may not transfer. > I can post the output if you think it of any value. 995 might be POP3, or you could run gnutls or openssl such that they try starttls. > It appears to be an intermittent problem, I suspect maybe the other end is doing some > load sharing or updating. > > In any event I will try to update soon as I can. OK, so if problems persist, please provide the log, per https://www.fetchmail.info/fetchmail-FAQ.html#G3 Regards, Matthias |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X