Certificat error using thunderbird with mail.ecloud.global

there is now a few days that every 10 minutes Thunderbird throw an error about certificate of my e.email account.

image

the image shows a security warning dialog in French from the Thunderbird email client. Here’s a translation and description:
*---------------------------------------------------------------------------------------------
“Adding a Security Exception”
Warning Message:

  • “You are about to bypass how Thunderbird identifies this site.”
  • “Banks, stores, and other legitimate public websites warn you not to do this.”
    Details:
  • Address field: e.email (partially filled)
  • “This site is attempting to identify itself with invalid information”
  • “The certificate is not safe because it is impossible to verify if it was issued by a trusted authority using a secure signature”
    Options:
  • “Get the Certificate” button
  • “See…” link to more details
  • Checkbox: “Keep this exception permanently”
  • Two buttons at the bottom: “Confirm Security Exception” and “Cancel”
    *---------------------------------------------------------------------------------------------

if I ask for the content its show

Certificate Details:

  • Subject Name: Kubernetes Ingress Controller Fake Certificate

  • Organization: Acme Co

  • Issuer: Same as Subject (Acme Co, Kubernetes Ingress Controller Fake Certificate)
    Validity Period:

  • Valid From: Tuesday, 25 Mar 2025 20:49:54 GMT

  • Valid Until: Wednesday, 25 Mar 2026 20:49:54 GMT
    Alternative Subject Names:

  • DNS Name: ingress.local
    Public Key Information:

  • Algorithm: RSA

  • Key Size: 2048 bits

Whatever I try, like obtain certificate, cancel or accept or confirm security exception, the same issue return a few minute later.
I am using “mail.ecloud.global” as server on port 993 and 587 (SSL/TLS)
my other account are not affected. (it may be the thunderbird calendar app as well, I have not checked this one)

any idea of what happening ?

1 Like

Probably something weird going in with your DNS. The cert you’ve hit is for a service called “ingress.local” and it’s picking up a cert from a kubernetes cluster somewhere. When I’ve tested the server it shows a cert from LetsEncrypt.

baggypants@fedoraworkstation:~$ openssl s_client  mail.ecloud.global:993
Connecting to 95.217.246.96
CONNECTED(00000003)
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=R11
verify return:1
depth=0 CN=mail.ecloud.global
verify return:1
---bash
Certificate chain
 0 s:CN=mail.ecloud.global
   i:C=US, O=Let's Encrypt, CN=R11
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Feb 15 00:08:53 2025 GMT; NotAfter: May 16 00:08:52 2025 GMT
 1 s:C=US, O=Let's Encrypt, CN=R11
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
---

strange, I’m using cloudflare 1.1 as nameserver same problem with quad9 9.9.9.9 … I’m about to investigate my own machine (I don’t have any kube on my machine I know about)

(this isn’t dns) - your thunderbird requests something on https at e.email - that serves the bogus acme certificate and what thunderbird doesn’t like, thus the warning. You can ofc ignore it. Could be a autoconfig request - but other than that I don’t know what it wants to fetch there.

I have the same issue and still somewhat hesitant to ignore it as @tcecyk suggested. Why would the e.email server all of a sudden start serving a wrong certificate?

1 Like

so autoconfig requests happen, but cert errors during the autoconfig phase are not surfaced (don’t need to as it’s probing wildly).

It’s the tail end of requests in the second screenshot when looking for the carddav / caldav well-knowns when thunderbird brings the error to the user.

/.well-known/carddav
/.well-known/caldav

I’m not sure thunderbird is supposed to check them? the autoconfig doesn’t set the endpoints (as of now). It could create those sections and point to their endpoints to avoid the error - but atm I think TB is overreaching. Bugzilla doesn’t have an entry on this yet.

request list screenshots

(it works for murena.io users because the cert is valid and sure the fix is to just do so too on e.email - but technically imo thunderbird has to handle this better. No dav entries in autoconfig, don’t probe and act up)

1 Like

on my side it is clearly the certificate for https://e.email that is showed.

after further investigation, some tcpdump, strace and so on, I have found on thunderbird some address-book relaying on https://e.email (from long time ago) that are sync from time to time. after unsubscribing, et re-enter with murena.io the alert seems t have disappear.

showcert.sh e.email
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            71:2f:43:f1:e2:e1:8c:b3:d1:a3:e8:94:ec:62:6f:6b
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=Acme Co, CN=Kubernetes Ingress Controller Fake Certificate
        Validity
            Not Before: Mar 25 20:49:54 2025 GMT
            Not After : Mar 25 20:49:54 2026 GMT
        Subject: O=Acme Co, CN=Kubernetes Ingress Controller Fake Certificate
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d0:ee:33:59:8d:50:a0:58:52:0d:42:b8:2e:38:
                    f8:b0:3d:06:1c:0a:14:25:f1:ac:3e:8c:91:0c:d6:
                    c6:ec:85:9a:94:bb:ba:27:7e:44:30:14:b9:f0:57:
                    a9:54:47:b7:0d:61:87:e8:60:41:3c:1b:84:8f:a6:
                    e8:e9:8e:75:bf:7f:cc:f4:1f:cf:ec:af:32:c4:90:
                    a5:57:93:04:f4:63:e3:f6:a0:6d:be:66:26:cd:07:
                    3a:f0:87:75:61:71:b4:9d:4f:e6:44:1c:1c:2e:65:
                    c6:4e:f7:75:f7:f6:4f:24:6c:b1:78:ba:6b:95:7a:
                    ab:da:4f:e0:12:fb:43:71:0c:09:cd:ad:76:6f:6f:
                    3b:aa:b2:5b:f1:52:66:16:38:86:1a:f1:61:76:d9:
                    45:5e:de:41:d5:19:68:a9:20:8a:7c:7b:06:95:b9:
                    a0:ce:bf:df:b5:f0:49:b0:16:dc:dd:be:c7:4c:0d:
                    ae:9b:74:e8:67:47:3a:88:fc:f7:86:27:f5:40:4b:
                    ab:02:b6:62:50:12:8e:cb:7f:aa:fa:98:81:2d:bf:
                    9c:ac:2d:a6:bb:ae:54:be:01:e1:2a:17:1a:3c:44:
                    f7:c8:5a:2f:fb:8f:b4:1c:ae:36:04:15:17:4a:9e:
                    aa:63:a8:91:37:2a:6d:00:b8:b7:28:9b:c3:51:21:
                    83:eb
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Alternative Name:
                DNS:ingress.local
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        94:d4:62:76:f9:e0:2a:63:8d:ba:5e:6e:0c:2d:fa:e0:fd:1d:
        53:33:72:c6:72:2c:97:35:3d:7b:7d:47:ea:3a:fd:a2:6d:ba:
        46:f5:d3:e1:1e:52:7a:98:8f:4f:7b:0f:40:92:0e:50:97:ef:
        42:71:22:7b:bd:11:2d:09:f0:cf:fa:29:15:82:8c:47:71:ad:
        3b:ed:b5:dd:8f:a8:4b:ea:f0:e5:e0:cb:38:1e:44:f0:81:c1:
        c1:89:7f:c3:2c:62:b5:9e:2f:4c:b7:e4:d5:1b:34:be:96:29:
        8d:71:c8:a4:bd:0d:73:d9:df:f1:86:89:3f:08:4c:62:83:08:
        93:6e:3b:ce:05:cb:7b:a0:d6:87:20:00:54:6f:27:a3:d7:96:
        1f:29:6d:89:f5:61:55:29:07:cc:78:a5:0d:61:48:2d:01:74:
        38:db:69:fe:07:e6:d3:48:e3:b8:cf:4d:58:26:e0:d6:65:1b:
        f1:ff:ab:0a:19:57:3b:e8:11:17:50:ad:e2:44:ca:f7:79:c2:
        b4:0c:db:81:23:55:09:24:87:ba:3c:96:be:be:95:c6:0e:66:
        fc:25:3f:88:77:0e:39:69:3c:97:b3:4a:89:bb:ed:60:52:f0:
        33:a9:00:11:33:b3:ad:dc:6f:c3:fc:ce:1e:7d:88:0a:bb:1b:
        7d:ec:ce:24
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
1 Like

this is solved now at murenas end