Thunderbird and Firefox basically share the same certificate store and management. Thunderbird simply has it's own copy of the Firefox stuff.

I have go daddy listed as a builtin certifying authority in my copy of Thunderbird. Have you checked yours? You appear to be posting from a Linux device and maintainers often modify the base program to suit the ideology of their distribution. So I would not find it particularly extraordinary to have custom certifying authorities list in a Linux built version.

Another thing I have seen in the past is a missing intermediate certificate for the CA so there is no link between the certifying authority and the certificate.

This is normally something we see on Windows due to SSL/TLS scanning being enabled in an anti virus product and the dodgy certificate the AV generates for itself is not added to the certificate store. The user is expected to add the certificate.

It might well however be your choice of ports. I have seen an increase over the years of Firefox simply refusing to connect on non standard ports, despite the information on port being supplied going.com:8080 for example. Try port 8443 and see if it gives a different result.

Matt, thanks. I posted this question from Linux, but the computer involved is Windows 10.

Other posts on this topic did blame anti-virus software, and gave workarounds for various ones, but overall recommended using Windows' AV, e.g. Windows defender -- which is what I am using.

Given that Thunderbird and Firefox share the same certificate store, they should both be pointing to the same cert. With Firefox I tried https://mail.ohprs.org:443 (just to see if the port made a difference). That connected, no problem, although it did appear to re-write the URL, so possibly not a definitive test.

On Thunderbird I tried port 8443, same verification error.

How would I check Thunderbird's built-in list of certifying authorities? I've googled for how to do that, but no luck.

How would I check for a missing intermediate certificate (although I would think that would be true for all workstations).

Should I post the cert info Thunderbird shows?

Mark Foley said

Given that Thunderbird and Firefox share the same certificate store, they should both be pointing to the same cert.

They share the same code, not the same store. Each program is entirely independent, so adding a certificate to one has no impact at all on the other. They should however start out with the same base certificate database.

With Firefox I tried https://mail.ohprs.org:443 (just to see if the port made a difference). That connected, no problem, although it did appear to re-write the URL, so possibly not a definitive test.

I suggested try port 8443 because that is the default port for SSL caldav. So your server should be listening on it, Receiving a https request from Firefox on port 443 the default for HTTPS should have seen your server simply supply a web page.

Is your caldav server configured for SSL? https://help.atmail.com/hc/en-us/articles/201388224-Configuration-of-CalDAV-and-CardDAV-via-SSL

On Thunderbird I tried port 8443, same verification error. How would I check Thunderbird's built-in list of certifying authorities? I've googled for how to do that, but no luck.

Open the options Preferences and select advanced, then select the and finally the certificates tab. Click the Certificates button.

In the certificates window Authorities tab the providers will be identified as Builtin

Manually added certificates will be shown in the Servers tab

How would I check for a missing intermediate certificate (although I would think that would be true for all workstations).

If they are all using the same version of Thunderbird that would probably be true. If they are not then the certificate stores could be different, especially if Mozilla have disallowed certificates for some reason. Examine the certificate and determine who issued it. then find the issuer in the list, if there is no direct link you have a problem. An easier way is go here https://www.htbridge.com/ssl/ and test the server They will soon identify lots of issues usually, especially with deprecated and obsolete cyphers.

Should I post the cert info Thunderbird shows?

I suggest trying the server test first. see what you get back there.

Clicked to early, only wrote half the reply. So duplicating to get the email out again. Mark Foley said

Given that Thunderbird and Firefox share the same certificate store, they should both be pointing to the same cert.

They share the same code, not the same store. Each program is entirely independent, so adding a certificate to one has no impact at all on the other. They should however start out with the same base certificate database.

With Firefox I tried https://mail.ohprs.org:443 (just to see if the port made a difference). That connected, no problem, although it did appear to re-write the URL, so possibly not a definitive test.

I suggested try port 8443 because that is the default port for SSL caldav. So your server should be listening on it, Receiving a https request from Firefox on port 443 the default for HTTPS should have seen your server simply supply a web page.

Is your caldav server configured for SSL? https://help.atmail.com/hc/en-us/articles/201388224-Configuration-of-CalDAV-and-CardDAV-via-SSL

On Thunderbird I tried port 8443, same verification error. How would I check Thunderbird's built-in list of certifying authorities? I've googled for how to do that, but no luck.

Open the options Preferences and select advanced, then select the and finally the certificates tab. Click the Certificates button.

In the certificates window Authorities tab the providers will be identified as Builtin

Manually added certificates will be shown in the Servers tab

How would I check for a missing intermediate certificate (although I would think that would be true for all workstations).

If they are all using the same version of Thunderbird that would probably be true. If they are not then the certificate stores could be different, especially if Mozilla have disallowed certificates for some reason. Examine the certificate and determine who issued it. then find the issuer in the list, if there is no direct link you have a problem. An easier way is go here https://www.htbridge.com/ssl/ and test the server They will soon identify lots of issues usually, especially with deprecated and obsolete ciphers.

Should I post the cert info Thunderbird shows?

I suggest trying the server test first. see what you get back there.

I suggested try port 8443 because that is the default port for SSL caldav. So your server should be listening on it, [...] Is your caldav server configured for SSL?

I'm using radicale CalDAV server. Yes it is configured for SSL. That took me quite some time at the beginning to sort out. The pertinent line in the config is:

ssl = True

And without that set, https://mail.ohprs.org:5232 gave problems on all workstations and CalDAV clients. The Radicale documentation is pretty, but lacks much detail. They used 5232 as the example port throughout; never mentioned 8443. Thanks for that info. I'll change all workstations in due time. However, than means changing the URLs on up to 9 calendars on each of 10 workstations. I'll not do that tonight!

Open the options Preferences and select advanced, then select the and finally the certificates tab. Click the Certificates button. In the certificates window Authorities tab the providers will be identified as Builtin

There were some missing words in your navigation path, but I got to it via (Windows) Tools > Options > Advanced > Certificates > Manage Certificates > Authorities. GoDaddy is listed there:

GoDaddy.com, Inc.

   Go Daddy Root Certificate Authority ... Builtin Object Token

The 'View' button shows exactly the same "issued by" info as I posted above (CN) Go Daddy Root Certificate Authority - G2, (O) GoDaddy.com, Inc.

Interestingly, in the 'Edit Trust' button, it says, "This certificate can identify websites ... mail users." It says nothing about CalDAV users, although I access the CalDAV server via https, so it seems like "website" should qualify.

All workstations are using the same version of Thunderbird, 68.0, but since they auto-update that may not be the version used when initially authenticating the certificate.

Examine the certificate and determine who issued it. then find the issuer in the list, if there is no direct link you have a problem.

Issuer seems to undoubtedly be Go Daddy, which is in the list.

An easier way is go here https://www.htbridge.com/ssl/ and test the server They will soon identify lots of issues usually, especially with deprecated and obsolete ciphers.

Great site! Thanks. I'll hang on to that. Yes, it found problems and gave me a C+ rating. Specific summary:

"PCI DSS Several obsolescent encryption methods flagged. The server has TLS 1.0 enabled. Since the 30th of June 2018 it is non-compliant with PCI DSS.

HIPAA - mostly obsolescent encryption methods and required methods not enabled.

NIST - does not support TSLV1.3"

Do you suppose Thunderbird is choking on one of these problems?