Hide Forgot
Description of problem: When trying to add a web calendar, evolution fails with "Unable to connect to 'CALENDAR-NAME': Cannot open calendar: SSL handshake failed" Version-Release number of selected component (if applicable): 3.10.2 How reproducible: always Steps to Reproduce: 1. Add calendar "On the Web" with URI "https://basecamp.com/1788133/calendar_feeds/c744724.ics?token=TlpObVZzMTVrQlBBeWg4Y3JiSFpwdz09LS05Z3JCNGNVL25sczJ3QXZNZVlheTN3PT0%3D--35f00ea56760b54c23e5c8397f7191250d4e24e4-715358" Actual results: an error is shown, a RESET TCP packet on wireshark Expected results: no error and no events (the calendar is empty)
Might be related to https://bugzilla.gnome.org/show_bug.cgi?id=660134
Thanks for a bug report. It's weird, you are supposed to be asked what to do with the certificate, whether you want to ignore the SSL error or reject connection, when the server certificate looks suspicious. Nonetheless, I tried to reproduce this with your URL and I see the same issue, no prompt for a certificate. Let's deal with this upstream, as this doesn't seem to be Fedora specific. I do not expect this being related to the old 3.2.x bug report from comment #1, thus I created a new bug for it [1]. Please see [1] for any further updates. [1] https://bugzilla.gnome.org/show_bug.cgi?id=719381
from the upstream bug: "gnutls-cli -d 9 basecamp.com" shows: |<3>| EXT[0x2370310]: Parsing extension 'SUPPORTED ECC/10' (4 bytes) |<2>| ASSERT: ecc.c:95 |<2>| ASSERT: gnutls_extensions.c:206 |<2>| ASSERT: gnutls_handshake.c:1734 |<2>| ASSERT: gnutls_handshake.c:2154 |<2>| ASSERT: gnutls_handshake.c:1383 |<2>| ASSERT: gnutls_handshake.c:2634 *** Fatal error: An illegal TLS extension was received. where: 92 if (session->security_parameters.entity == GNUTLS_CLIENT) 93 { 94 /* A client shouldn't receive this extension */ 95 return gnutls_assert_val(GNUTLS_E_RECEIVED_ILLEGAL_EXTENSION); 96 } So, basically, basecamp.com is sending a TLS extension that is only defined for clients, not servers, and gnutls, being anal like it is, aborts at that point. File a bug against basecamp I guess? You can kludge around this by running e-d-s with G_TLS_GNUTLS_PRIORITY="NORMAL:%COMPAT:-ECDHE-RSA" set in the environment, which will keep e-d-s (and any other glib-tls-based code in that environment) from negotiating elliptic-curve encryption, thus bypassing the server bug.