1700044 - When using a self-signed certificate for Davical server with non-standard port number, it is no longer permanently accepted, even if told so

Status: UNCONFIRMED

(Calendar :: Provider: CalDAV, defect)

Description

[fr]

Attachment: Annoying dialog

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:86.0) Gecko/20100101 Firefox/86.0

Steps to reproduce:

I have a Davical calendar that uses a self-signed certificate. Normally, Thunderbird should accept it after being told so (Save exception permanently). The certificate is listed in the list of the settings dialog.

Actual results:

I get dozens of warning messages as my request to Accept the certificate permanently is ignored

Expected results:

Invalid/self-signed certificate should be accepted permanently

Comment 1

[fr]

Attachment: Bildschirmfoto zu 2021-03-22 09-14-58.png

Comment 2

[fr]

Any news on this case? I am really tired of clicking away 30 messages every time I wake up my PC.

Comment 3

[Wayne Mery (:wsmwk)]

Richard, any insight into comment 0?

Comment 4

[Richard Leger]

(In reply to Wayne Mery (:wsmwk) from comment #3)

Richard, any insight into comment 0?

@fr,

Have you tried:

• replace your current self-signed certificate with one which is not expired? We are well past Jul 2015 :-) Just re-generate a new self signed one...
• in the last version TB 78.11.0 (is it run on Linux, Windows or else?)
• to remove the certificate exception from the certificate manager windows first, prior re-setting the permanent exception?
• with another caldav client than Thunderbird
• access your calendar via a Get request in Firefox something like: https://192.168.2.84/davical/caldav.php/fr/calendar (this is just an example you need to adjust the path to the correct one on your system, I assume here that 192.168.2.84 is your calendar server, running a Davical caldav instance but you may be using something else so the path might be slightly different for you). This way you should be able to check if Firefox can see and handle properly the self signed certificate exception or not?

Let us know how you get on with the above...
Sorry all my caldav instance run free Let's Encrypt or commercial valid certificates so I can no longer test with a self-signed one at the minute...

Cheers,
Richard

Comment 5

[fr]

Thanks very much for helping me. The problem was that the server is running on port 18443 instead of 443. When I added the port in the warning dialog, i.e. [server]:18443, and confirmed the exception, sync became operational again, no more error/warning messages. I took the chance to renew the self-signed certificate, but that did not have an effect (other than making me experiment a bit...). Thanks again, also for your patience.

Felix

Comment 6

[Richard Leger]

(In reply to fr from comment #5)

Thanks very much for helping me. The problem was that the server is running on port 18443 instead of 443. When I added the port in the warning dialog, i.e. [server]:18443, and confirmed the exception, sync became operational again

@fr
Well done and thanks for.your feedback. When you setup you caldav account I suspect you did set the port correctly no?
So in theory TB shall have it detected for the exception, it shall not have assumed 443...

@Wayne
Do you think that may be a bug in TB as not using properly the account settings port when trigerring exception request to end-user?

Comment 7

[Wayne Mery (:wsmwk)]

Do you think that may be a bug in TB as not using properly the account settings port when trigerring exception request to end-user?

Maybe? I've CC others who should have a more informed opinion

Comment 8

[Ben Bucksch (:BenB)]

Reporter claims that his server has port 18443, but TB saved an exception for port 443, so that theory makes sense. However, the question is what exactly the reporter entered, and where.

@fr (Reporter): Please give reproduction steps, starting with a fresh profile. Particularly, which exact and concrete caldav URL do you enter (including port, if you used a port number!), and where exactly you enter it. Is that Lightning, or an extension? Please make a screenshot of the dialog where you enter your server URL. (You may blank out your domain name and user name, but nothing else.) Please follow https://secure.phabricator.com/book/phabcontrib/article/reproduction_steps/

Comment 9

[fr]

Ok, assume the calendar address is https://whatever.com:18443/davical/caldav.php/felix/calendar/
The message allowing to add the certificate exception proposes
https://whatever.com
(over and over again, unless you know that you need to add :443 manually). I hope this quick reply will be useful for you, going through the steps one by one will take more time. I am a developer myself, so I can kinda imagine how the code looks like, and that it currently assumes that the standard port of the protocol is used, i.e. the case "port is not equal to the standard one" is not covered - which probably works for most cases...

Comment 10

[fr]

Attachment: tb91.5.0_x64_Linux_cert_prob.png

The update to TB 91.5.0 recent brought the bug back.

Comment 11

[fr]

Attachment: error_msgs.png

Buy one error message, get 5 free

Comment 12

[Magnus Melin [:mkmelin]]

I think bug 1750655 fixed this. Can you confirm using daily? http://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-central/