Could not verify this certificate because the issuer is unknown
I've just subscribed to a CalDAV calendar on a newly installed Thunderbird (68.0) on a new Windows 10 computer. After subscribing I get a "Add Security Exception" dialog with the following messages, "This site attempts to identify itself with invalid information. Unknown Entity. The certificate is not trusted because it hasn't been verified as issued by a trusted authority using a secure signature." I've done 'Get Certificate' and 'View'. The security cert is issued by "Go Daddy Secure Certificate Authority - G2", valid from 6/3/2019 through 8/15/2021. Go Daddy seems like a "trusted authority" to me (we've been using Go Daddy for 6 years).
A further oddity is that I've subscribed to the same CalDAV calendars on 11 other computers in the office over the past few months on Windows 7, Linux, Mac (Thunderbird and Mac mail), and Windows 10 (Thunderbird and Outlook with calDavSync plug-in). All have worked fine with no security exceptions needed. The only difference is this security certificate is new (June 3rd) whereas the old cert expired on August 15th -- all other workstations subscribed to the CalDAV calendars before that. However, I would expect the other workstations to now also be validating with the new cert, yet no problems reported. The CalDAV server is locally hosted and I have confirmed that it is pointing to the new cert.
Firefox is able to use https and this cert (confirmed cert in httpd.conf) with no such warning.
Thought: the URL for the CalDAV calendar is https://mail.ohprs.org:5232/... could the port number be messing up verification? It did not do so on the previous calendar subscriptions on the other workstations.
I am running Windows Defender on this Windows 10 computer.
I'd rather not create an exception if there is something I can do to fix this on the client.
All Replies (5)
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?
Modified by Mark Foley
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.
Modified by Matt
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?
Modified by Mark Foley