Thank you for your reply!

I tried both options. None of them worked.

I did as you said. The error message is:

>2018/03/19, 01:26:54: FETCH - Owner: "pop.xs4all.nl".
>2018/03/19, 01:26:54: FETCH - Issuer: "US", "Let's Encrypt", "Let's Encrypt Authority X3". Valid from 3/17/2016 4:40:46 PM to 3/17/2021 4:40:46 PM. The issuer of this certificate chain was not found!
>2018/03/19, 01:26:54: FETCH - Missing issuer: "Digital Signature Trust Co.", "DST Root CA X3".
!2018/03/19, 01:26:54: FETCH - TLS handshake failure. Invalid server certificate (The issuer of this certificate chain was not found).
2018/03/19, 01:26:55: FETCH - TLS handshake complete
2018/03/19, 01:26:55: FETCH - connected to POP3 server
2018/03/19, 01:26:55: FETCH - authenticated (plain)
2018/03/19, 01:26:55: FETCH - 212 messages in the mailbox, 0 new
2018/03/19, 01:26:55: FETCH - TLS connection completed successfully
2018/03/19, 01:26:55: FETCH - connection finished - 0 messages received

I've contacted XS4ALL. They say they renewed their certificates, and that Ritlabs is to blame.

The "DST Root CA X3" issuer in the latest error message is new.

Have you verified that it is in your address book? (If you have an older version of The Bat, it may not be there. It would be strange if the certificate is there but you are still getting that error message..)

If you don't have this root certificate after all, I'd recommend that you download and import the .pem version from this page:

https://ssl-tools.net/subjects/6ff4684d4312d24862819cc02b3d472c1d8a2fa6

(it's the top-most, 'self-signed' certificate in the list there).

XS4ALL is a good provider, but the fact that they changed their certificate long before it expired suggests that more users must have been having problems with it.

In Account Properties | Transport | Receive Mail, is the Connection field set to 'Secure to dedicated port (TLS)' and the Port to 995?

If that doesn't work, I'd try Connection: 'Secure to regular port (STARTTLS)'.


According to www.sslchecker.com/sslchecker, xs4all's certificate is valid for:

           X509v3 Key Usage: critical
               Digital Signature, Key Encipherment
           X509v3 Extended Key Usage:
               TLS Web Server Authentication, TLS Web Client Authentication

(I checked for pop.xs4all.nl, port:995 there)

It doesn't say anything about Email or Emailprotection, so, maybe The Bat is right that the certificate is not fit for this purpose. It is also strange that this certificate will only be valid for three months (it expires May 13, 2018). The sslchecker.com site also reports a missing "DST Root CA X3" (just like The Bat did on your system), which suggests that not all major parties on the internet (who make browsers and devices) trust it yet. I find it strange that xs4all would be using such a certificate chain, it all seems a bit experimental to me.

At any rate, if you can't get it to work now, I think the most plausible explanation is that The Bat is right and xs4all's certificate may not be valid for email protection. Which would be weird because many more xs4all customers would be complaining if that's true. If you write to xs4all's helpdesk again and nothing useful comes out, I'd ask for escalation of your support request to a senior technician (and maybe refer him to this thread).

Hello!

Don't be fooled by the "TLS Web Server Authentication" and "TLS Web Client Authentication". It's just a common name for basic server/client certificate authentication. Our previous wildcard-certificate from COMODO CA had exactly the same Extended Key Usage defined, as can be seen on https://crt.sh/?id=163808376.

All Let's Encrypt certificates are only valid for 3 months, which no difference for the validity of the certificate. If anything, renewing more often only adds to security, especially when combined with a new private key per renewal.

The certificates are not only perfectly valid for this usage, 99% of all of our connecting clients accept this, and the last 1% are ancient, by their vendor unsupported clients (e.g. Outlook 2003, Exchange 2010, fetchmail and alike). And mostly because they either 1) Don't understand Subject Alternative Name (fetchmail), or 2) Don't have the Let's Encrypt Root CA in their trust store as the trust store is too old.

The latter seems to be the case with The Bat, which you already seem to have resolved by importing the required Root CA certificates.
Let's Encrypt has issued over 100 million certificates to date, and is possibly the largest certificate provider in the world at this very moment. It's run by the Linux Foundation, funded by Google, Microsoft, Mozilla (who even have employees at Let's Encrypt), Akamai, HP, Cisco and alike. Their technical advisory board consists of Akamai, Mozilla, Google, the Internet Society, and the Electronic Frontier Foundation (who also have employees there).

The DST Root CA (IdenTrust) was only used to cross-sign their initial CA, because DST was already in trust stores, please see: https://letsencrypt.org/certificates/

I believe that stating the problem is with Let's Encrypt and us is incorrect, and needs resolving in The Bat. Other than the Root CA changing to an -apparently- unknown one and now being a specific certificate requiring support for X509v3 SAN extensions (due to not being a wildcard), no ciphers/protocols have changed.

Kind regards,

Daniël Mostertman
System Engineer at XS4ALL Internet bv

The Microsoft Certificate Store lists DST Root CA X3. However, using it in TheBat! gives:

2018/03/21, 23:56:51: FETCH - Connecting to POP3 server pop.xs4all.nl on port 995
2018/03/21, 23:56:51: FETCH - Initiating TLS handshake
>2018/03/21, 23:56:51: FETCH - Certificate S/N: 0464978330EDB9023980833E045392CF656E, algorithm: 1.2.840.10045.2.1 (384 bits), issued from 2/12/2018 12:35:40 PM to 5/13/2018 12:35:40 PM, for 8 host(s): mail.xs4all.nl, pop-ipv4.xs4all.nl, pop-ipv6.xs4all.nl, pop.xs4all.nl, pop3.cistron.nl, pop3.demon.nl, pop3.xs4all.nl, pops.xs4all.nl.
>2018/03/21, 23:56:51: FETCH - Owner: pop.xs4all.nl.
>2018/03/21, 23:56:51: FETCH - Issuer: US, Let's Encrypt, Let's Encrypt Authority X3.
!2018/03/21, 23:56:51: FETCH - TLS handshake failure. Invalid server certificate. The certificate cannot be used for this purpose

I didn't manage to succesfully get The Bat! to work for me (the Window of the Wizard just disappears), but while taking another look at the errors you showed, I think I might have an idea as to what is going on:

2018/03/20, 15:06:23: FETCH - Certificate S/N:  0464978330EDB9023980833E045392CF656E, algorithm: ECC (384 bits), issued  from 2/12/2018 12:35:40 PM to 5/13/2018 12:35:40 PM, for 8 host(s):  pop.xs4all.nl, mail.xs4all.nl, pop-ipv4.xs4all.nl, pop-ipv6.xs4all.nl,  pop3.cistron.nl, pop3.demon.nl, pop3.xs4all.nl, pops.xs4all.nl.
2018/03/20, 15:06:23: FETCH - TLS handshake failure. Invalid server  certificate (The certificate cannot be used for this purpose).

Since we switched to Let's Encrypt, we issue all certificates twice. Once with a 4096-bit RSA-key, and once with a 384-bit EC-key. It seems The Bat! is connecting using the EC-certificate, but the SSL-library it is using can not make the connection (can't agree on a cipher?). It's late now, and I can't debug much further, but if there is any way of specifically setting/testing a specific cipher or forcing the use of the RSA-certificate (instead of the EC), that might help.

Edit: Maybe it wasn't entirely clear, but we have both types of certificates active, and the client can choose by itself whether to go for RSA or EC.

I should add that it's a first that a provider actually comes to forums to help debugging - that is incredible and something I really appreciate. Thank you very much for your time. Hopefully our friends from Moldavia will actually respond, because until now their response time has been far from impressive (it has been like that for 15 years and I'm afraid it will never improve).

Just for the record: The mentioned site does exactly the same thing for www.google.com's certificate I wouldn't put much stock in it not having the Root CA certificate. Seems it doesn't have any current one.

Daniel, it works! The service of XS4ALL, indeed one of the premier ISP's in Holland, is incredible compared to the deafening silence from our friends in Moldavia. It puts them to shame, to be honest.

Thank you very much, and I hope Ritlabs will come up with a final solution in a few centuries or so, so that you can re-enable the EC certificate.

Very happy to help, and glad it's resolved!

That was exactly what I was looking for, thanks! With that I managed to get the Wizard again, and set up a test-account in it. Everything works out of the box now (latest version of The Bat! on Windows 10 Enterprise here). I didn't need to import any Root CA's or anything, just worked as-is.. so I think the first problem might've had to do with the EC-certificate as well(?).

Have a nice day