General discussion on installation and configuration of SOGo

Text archives Help


Re: [SOGo] Calendars locked


Chronological Thread 
  • From: Adi Kriegisch < >
  • To:
  • Subject: Re: [SOGo] Calendars locked
  • Date: Tue, 8 Sep 2015 18:47:05 +0200

Hey,

> My calendars locked again yesterday. The trick of changing their
> readonly and disabled status via the configuration editor and then
> restarting Thunderbird once again fixed them. This time I was able
> to copy the errors from the Thunderbird log (attached) and match
> them to Apache errors on my SOGo server caused by the StartCom OCSP
> server being off-line once more.
There is a bug in Lightning[0] for which a patch exists[1] and a nightly
build is available[2] (without localization and all that). The Mozilla
Lightning team will roll out an updated Lightning version real soon now or
in two weeks -- depending on whom you ask. (And I have no idea if this will
be v4.0.2.1 or v4.0.3).
There also is a bug entry[3] in SOGo's bug tracker providing that
information. So either use the nightly build or manually patch your version
of Lightning and roll it out via your update mechanism or locally patch the
source (luckily there are just javascript files to patch) of the installed
plugin.

> Hunting through Thunderbird I have now found in Preferences ->
> Advanced -> Certificates that there is a "Query OCSP responder
> servers to confirm the current validity of certificates" setting. It
> is enabled on my installation and I am going to disable it to see if
> it helps. As OCSP stapling on my Apache (SOGo) server should do
> this verification, my belief is that having the client do it too is
> redundant. Certainly Google have retired this feature from their
> Chrome browser, so they clearly don't see the value.
The problem itself has nothing to do with OCSP but with a race when
initializing and establishing a connection.
To fix the trouble with OCSP you definitely want to use and configure OCSP
stapling on the web server side. OCSP stapling does *not* validate the
certificate on the server side (which would be utterly useless) but caches
a valid OCSP response for some time and sends it to the client to
streamline the process of certificate validation. An OCSP response is
signed by the OCSP server and has -- as with all SSL certs -- a certain
validity time span within which it is considered to be valid. Validation
itself still has to be done by the client.
Common sources of trouble with OCSP can be:
* time drift on the client (system clock off more than some hours)
* OCSP stapling not configured
* OCSP stapling configuration wrong:
- Apache has no OCSP responder configured (no AIA extension in
certificate); so you could try to set one with SSLStaplingForceURL
- cache time too long/short (try to find out how long an OCSP response
is valid at your favorite snakeoil seller)
Anyways, there are many tutorials[4] out there helping with correctly
setting that up.

-- Adi

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1195974
[1] https://hg.mozilla.org/releases/comm-esr38/rev/839f27cac475
[2]
https://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/tinderbox-builds/
[3] http://www.sogo.nu/bugs/view.php?id=3325
[4] https://raymii.org/s/tutorials/OCSP_Stapling_on_Apache2.html



Archive powered by MHonArc 2.6.18.

Top of page