1

After upgrading to Thunderbird 102 (from whatever the previous version on the Ubuntu 20.04 repos was), I can no longer connect to the CalDAV server I run. Thunderbird refuses the certificate, claiming it belongs to a different site.

The FQDN by which I connect to the server matches the common name of the certificate, and the certificate has not expired – I have verified both these things.

The certificate was issued by a private CA, whose certificate I added to the store long before the upgrade. I was able to connect to the server before the upgrade.

Even defining a security exception does not work: every time I refresh, I get the same certificate error.

My smartphone has no problems connecting to the same server with DAVx⁵.

If I try to connect to the server with Firefox 105.0, I get a similar error (SSL_ERROR_BAD_CERT_DOMAIN) but can connect after adding a security exception. (Since Firefox shares some code with Thunderbird, they might also share certain bugs or unexpected behavior.)

The certificate does not specify any purposes for key usage – I have seen some other applications have started rejecting certificates because of this, so I am wondering if this could be the issue (in which case the error message would be misleading).

Any ideas?

Improve this question
4
  • Try visiting the server using a web browser or command line tool to see if you can connect (change the url to FQDN:calDavServicePort)
    – Ram
    Commented Oct 8, 2022 at 16:27
  • See updated question. I also get a bad cert domain error, but can connect after adding a security exception.
    – user149408
    Commented Oct 8, 2022 at 16:35
  • Does the certificate have a subjectAltName extension, and if so, does the extension include the domain name you're connecting to?
    – grawity_u1686
    Commented Oct 8, 2022 at 16:49
  • No, the FQDN equals the Subject Common Name. The cert has no subjectAltName extension.
    – user149408
    Commented Oct 8, 2022 at 17:16

1 Answer 1

Reset to default
2

The FQDN by which I connect to the server matches the common name of the certificate

The use of common name to specify the FQDN is obsolete for ages. Instead Subject Alternatives Names should be used. Support for CN was removed many years ago in Google Chrome and it looks like it is removed in NSS (TLS library for Mozilla products, including Thunderbird) since a few month too.

Apart from that there seemed to be a bug in asking the user to accept the wrong certificate - see Suddenly Thunderbird does not retrieve imap mail - cert override dialog doesn't come up. This should be fixed in the latest releases though.

Improve this answer
2
  • I'd like to reinforce that Subject Alternative Names must be used. Browsers will not accept the certificate otherwise.
    – Daniel B
    Commented Oct 8, 2022 at 20:05
  • Indeed, after replacing the certificate with one that has the FQDN as a subjectAltName, everything works again as it should.
    – user149408
    Commented Oct 9, 2022 at 10:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .