Important Notice: We're experiencing email notification issues. If you've posted a question in the community forums recently, please check your profile manually for responses while we're working to fix this.

Kërkoni te Asistenca

Shmangni karremëzime gjoja asistence. S’do t’ju kërkojmë kurrë të bëni një thirrje apo të dërgoni tekst te një numër telefoni, apo të na jepni të dhëna personale. Ju lutemi, raportoni veprimtari të dyshimtë duke përdorur mundësinë “Raportoni Abuzim”.

Mësoni Më Tepër

Need to clear Lightning client certificate cache (switching to new client certificate)

  • 2 përgjigje
  • 4 e kanë hasur këtë problem
  • 1 parje
  • Përgjigjja më e re nga spacewrench

more options

I use Lightning (2.6.4 on Thunderbird-Mac 24.4.0) to display appointments and tasks from several calendars on a Davical CalDAV server. The server uses HTTPS and requires a client certificate to access. This has all been working well, until I got a new certificate during Heartbleed cleanup.

Lightning appears to be continuing to use the old client certificate (even after I deleted it). The server reports a certificate verification error, but I don't know whether it's sending the old cert, nothing, or garbage. At any rate, it doesn't appear to be sending the new certificate.

The new certificate works, though: if I add a calendar using a DNS alias to the same server, then Lightning asks which client cert to use, and is able to connect to the CalDAV server using the new certificate.

I have several users and several calendars, so I'd prefer not to change all of them over to the DNS alias.

Is there any way to clear the SSL cache so that Lightning asks again which client cert it should use for a CalDAV server connection?

Thanks,

I use Lightning (2.6.4 on Thunderbird-Mac 24.4.0) to display appointments and tasks from several calendars on a Davical CalDAV server. The server uses HTTPS and requires a client certificate to access. This has all been working well, until I got a new certificate during Heartbleed cleanup. Lightning appears to be continuing to use the old client certificate (even after I deleted it). The server reports a certificate verification error, but I don't know whether it's sending the old cert, nothing, or garbage. At any rate, it doesn't appear to be sending the new certificate. The new certificate works, though: if I add a calendar using a DNS alias to the same server, then Lightning asks which client cert to use, and is able to connect to the CalDAV server using the new certificate. I have several users and several calendars, so I'd prefer not to change all of them over to the DNS alias. Is there any way to clear the SSL cache so that Lightning asks again which client cert it should use for a CalDAV server connection? Thanks,

Krejt Përgjigjet (2)

more options

I assume these are SSL certificates, so Tools menu (Alt+T) > options > advanced > certificates

more options

The path to get there is a little different on a Mac, but yes, that's the right place. The problem is, even after I delete the old client certificate, install the new client certificate, reboot and restart Thunderbird, it appears to be presenting the same old certificate.

The only way I've found to move forward is to change the URL of the CalDAV server (by adding a DNS alias). So Thunderbird is talking to exactly the same machine, but (I surmise) when it looks in the certificate database for "which client certificate should I send to this server?" it doesn't find a match because of the different DNS name. So it asks me which certificate to send, I select the new certificate, and everything is fine.

After running for a few days with the new DNS name, I just now stopped Thunderbird, edited prefs.js to switch the DNS name back, and restarted. It asked me for the client certificate to send, and appears to be working OK. So I'm not sure what happened or why, but the solution for me was to change DNS names, run for a while, and then change back. It would've been easier if there was a "forget which certificate goes with which server" option, though!

Thanks,