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.

After a quick debugging, the SoupMessage has "properly" set its status_code to SOUP_STATUS_SSL_FAILED, but it doesn't contain any information about the failure, aka the soup_message_get_https_status() call on the SoupMessage instance fails, the cert is NULL and flags 0, which is treated as "always reject to connect there", mainly because there is nothing to show to the user.

Dan, can this be some issue in libsoup? I recall there used to be one similar, but I hoped the 2.44.2 may have it already fixed.

I forgot to mention, the soup_session is created with these flags:
	soup_session = soup_session_sync_new ();
	g_object_set (
		soup_session,
		SOUP_SESSION_TIMEOUT, 90,
		SOUP_SESSION_SSL_STRICT, TRUE,
		SOUP_SESSION_SSL_USE_SYSTEM_CA_FILE, TRUE,
		NULL);

https://git.gnome.org/browse/evolution-data-server/tree/calendar/backends/http/e-cal-backend-http.c#n174

(In reply to comment #2)
> After a quick debugging, the SoupMessage has "properly" set its status_code to
> SOUP_STATUS_SSL_FAILED, but it doesn't contain any information about the
> failure, aka the soup_message_get_https_status() call on the SoupMessage
> instance fails, the cert is NULL and flags 0, which is treated as "always
> reject to connect there", mainly because there is nothing to show to the user.
> 
> Dan, can this be some issue in libsoup? I recall there used to be one similar,
> but I hoped the 2.44.2 may have it already fixed.

I think the situations that are actual cert rejections should all be fixed, but SOUP_STATUS_SSL_FAILED will also be returned for any other error originating from gnutls. In unstable libsoup you get the text of the error in msg->reason_phrase, though I think that was a post-2.44 improvement. Anyway:

    danw@laptop:examples (master)> ./get 'https://basecamp.com/1788133/calendar_feeds/c744724.ics?token=TlpObVZzMTVrQlBBeWg4Y3JiSFpwdz09LS05Z3JCNGNVL25sczJ3QXZNZVlheTN3PT0%3D--35f00ea56760b54c23e5c8397f7191250d4e24e4-715358'
    /1788133/calendar_feeds/c744724.ics: 6 Error performing TLS handshake: An illegal TLS extension was received. (no handshake status)

"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.