Pages: Prev. 1 2
RSS
Invalid mai certicate
 
I have been able to connect to pop.xs4all.nl with The Bat! version 8.3. Here is the log:


23.03.2018, 18:57:10: FETCH - receiving mail messages
23.03.2018, 18:57:10: FETCH - Connecting to POP3 server pop.xs4all.nl on port 995
23.03.2018, 18:57:10: FETCH - Initiating TLS handshake
>23.03.2018, 18:57:10: FETCH - Certificate S/N: 0493EF61A34F0A959C13663FDCB9D95997BD, algorithm: RSA (4096 bits), issued from 2/12/2018 12:35:29 PM to 5/13/2018 12:35:29 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.
>23.03.2018, 18:57:10: FETCH - Owner: "pop.xs4all.nl".
>23.03.2018, 18:57:10: 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.
>23.03.2018, 18:57:10: FETCH - Root: "Digital Signature Trust Co.", "DST Root CA X3". Valid from 9/30/2000 9:12:19 PM to 9/30/2021 2:01:15 PM.
23.03.2018, 18:57:10: FETCH - TLS handshake complete
23.03.2018, 18:57:10: FETCH - connected to POP3 server

The error message "The certificate cannot be used for this purpose" that The Bat! gave in the above messages means that the certificate was good but have not been issued for this purpose. If a certificate has an "extended key usage" property (extKeyUsage), than, for a server like a POP3 server there should be "serverAuth" purpose included. If there is just a basic "key usage" property in the certificate, it should have ("keyEncipherment" or "ku_keyAgreement") AND (digitalSignature).

So the problem is not with the elliptic curves but with a key usage. Could you please post us a link where we can download and see this EC certificate?
 
Maybe we should make sure that a certificate has more "orthodox" attributes when it comes to key usage!?
 
I hope Daniël returns with the EC certificate to see if The Bat was right to reject it. Maybe The Bat, with its strong emphasis on safety and security, is more strict than other email clients.

Maxim, would it be possible/desirable for The Bat to perform another log-in and choose a different server certificate when the first certificate is rejected (instead of just giving up)?
I volunteer as a moderator to help keep the forum tidy. I do not work for Ritlabs SRL.
 
Quote
Daniel van Rooijen wrote:
Maxim, would it be possible/desirable for The Bat to perform another log-in and choose a different server certificate when the first certificate is rejected (instead of just giving up)?
It is just what server returns. There is no choice on the client part.
 
Hi Maxim, I contacted Daniël Mostertman, who was very busy, but he told me the 384-bit EC certificate can be found here:

https://crt.sh/?id=328483187   (you'll find a download link for the .pem version in the left margin).

XS4ALL's other certificate, 4096-bit RSA signed, is https://crt.sh/?id=328483121

Daniël suggested that the problem might be caused by the unusual circumstance that they are (well, 'were', for the time being) offering two certificates. As he mentioned earlier in this thread, their server offers both certificates and the mail client can choose which one to use, EC or RSA.
I volunteer as a moderator to help keep the forum tidy. I do not work for Ritlabs SRL.
 
As I have mentioned in an earlier post, the problem was not in a certificate iteself but that it was used by server admins for incorrect purpose.
This was confirmed by the "The certificate cannot be used for this purpose" line in the log. If a certificate has an "extended key usage" property (extKeyUsage),  than, for a server like a POP3 server there should be "serverAuth"  purpose included. If there is just a basic "key usage" property in the  certificate, it should have ("keyEncipherment" or "ku_keyAgreement") AND  (digitalSignature). But the certificate in your case didn't have that purposes that would have allowed it to use on the server.
Pages: Prev. 1 2