Errors from browser-based email client

Just wanted to chime in and say that this is a problem for us too, except that we're using it for our email services. Suddenly our browser based email clients stopped working. Doesn't seem to be a problem on device email or desktop email clients.

When I run this command on a just renewed cert, I get the following:

openssl s_client -connect our.domain:443 -servername our.domain
CONNECTED(00000003)
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT

How can this happen as I forced renewal of the cert 1 hour ago?

Still not clear on what the solution is here from reading the thread above...

Hi @Asai, welcome to the forum! Please provide your actual domain name. That way we can issue requests against it to see what certificate chain it's serving.

Also, what operating system version and what browser are you getting errors on? What are the exact errors you get from the browsers?

2 Likes

@jsha, thanks for the response.

The domain I tested was triata4.globalchange.media.
It's running on CentOS 7.

This cert is just for a single webmail instance that's behind a firewall, I'm not sure if you'll be able to contact it directly, but I can work with you on this. It's not throwing any errors in a browser, but when I run that openssl command outlined above from the server it's running on that's what I get. So... bizarre.

What happened this morning was that this webmail client started throwing errors about not being able to validate the email server over TLS because the server cert was expired (email server was also running LetsEncrypt cert). I have since replaced our email server cert with a RapidSSL cert which solved the problem temporarily, but would rather go back to using LetsEncrypt.

1 Like

This is curious because email is generally known to encrypt with any cert (even self-signed certs).
Do you happen to have any details on those errors?

Sure.

This is from the Dovecot logs. This behavior had started about 2 hours previously.

Sep 30 10:23:53 triata4 dovecot: imap-login: Disconnected: Connection closed: SSL_accept() failed: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca: SSL alert number 48 (no auth attempts in 0 secs): user=<>, TLS handshaking: SSL_accept() failed: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca: SSL alert number 48, session=<0kn+tTnNQKIKAQFj>

This is from the webmail client logs:

[30-Sep-2021 10:23:53 America/Phoenix] PHP Warning:  stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages:
error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed in rcube_imap_generic.php on line 1087
[30-Sep-2021 10:23:53 -0700]: <rsulenie> IMAP Error: Login failed for xxxx@xxxxxx against triata.globalchange.media. Unable to negotiate TLS in rcube_imap.php on line 200 (POST /?_task=login&_action=login)

We'd really need to see the certificates send by Dovecot. Please provide the mailservers hostname, assuming it's a public facing services.

triata.globalchange.media:993 ?
If so, then:

openssl s_client -connect triata.globalchange.media:993
CONNECTED(00000005)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1
verify return:1
depth=0 CN = triata.globalchange.media
verify return:1
---
Certificate chain
 0 s:CN = triata.globalchange.media
   i:C = US, O = DigiCert Inc, CN = RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1
 1 s:C = US, O = DigiCert Inc, CN = RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
 2 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
---

Hhm, missed the hostname there..

But that doesn't seem to be a Let's Encrypt certificate. So either not a Let's Encrypt issue or not the correct mailserver. :stuck_out_tongue:

He previously stated:

But now, even with an other CA cert, somehow continues to have problems...

1 Like

Thanks for everyone's replies here.

This is probably a bit confusing. There were 2 LE certs running on this server (now one):

  1. triata.globalchange.media (the email server, replaced by a RapidSSL cert)
  2. triata4.globalchange.media (the webmail client)

The error I got from the first post in this thread (the openssl command) was to verify triata4. It seems that this is still occurring as I just ran the command again from the server's cli and I would assume that if it's happening for this cert, it would probably happen for the other cert as well:

[root@triata4 ~]# openssl s_client -connect triata4.globalchange.media:443 -servername triata4.globalchange.media
CONNECTED(00000003)
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
---
Certificate chain
 0 s:/CN=triata4.globalchange.media
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
1 Like

Client?
OR
Server?

Oh @rg305 isn't it the other way around? :rofl:

Server?
OR
Client?

:rofl:

1 Like

Indeed. It's a webmail application running under that domain name that's on the same hardware as the email server.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.