I just saw that the problem might have to do with akonadi & openssl ... versions incompatible:
> qt.network.ssl: Incompatible version of OpenSSL
> qt.network.ssl: QSslSocket::startClientEncryption: TLS initialization failed
> qt.network.ssl: QSslSocket::startClientEncryption: TLS initialization failed
> org.kde.pim.davresource: Unable to fetch collections 300 "Bei der Abfrage ist ein Problem aufgetreten\nHTTP-Fehler (0)."
> qt.network.ssl: QSslSocket::startClientEncryption: TLS initialization failed
> qt.network.ssl: QSslSocket::startClientEncryption: TLS initialization failed
> org.kde.pim.davresource: Unable to fetch collections 300 "Bei der Abfrage ist ein Problem aufgetreten\nHTTP-Fehler (0)."

Perhaps the people who built the flatpak could help.
If you installed the one from Flathub, I think their issue tracker is
https://github.com/flathub/org.kde.kontact/issues

i got the same issue with deb packages for freshly installed kubuntu 22.04 (kubuntu backports, kontact 5.20). i have two machines still running kubuntu 20.04 (kontact 5.13.3), both connect flawlessly with the same nextcloud server.

I use KOrganizer 5.20.0 successfully with two different Nextcloud servers, 
running on KDE Neon (which is basically Ubuntu 20.04).  As a wild guess, perhaps
the minimum supported TLS version was raised in Kubuntu 22.04?

(In reply to gjditchfield from comment #4)
> I use KOrganizer 5.20.0 successfully with two different Nextcloud servers, 
> running on KDE Neon (which is basically Ubuntu 20.04).  As a wild guess,
> perhaps the minimum supported TLS version was raised in Kubuntu 22.04?

looks like it:

https://askubuntu.com/a/1407781

however, i can login to the same nextcloud server with a web browser without warnings. the same server also runs seafile behind the same apache, and neither the seafile desktop client nor web browser have any problems reaching it. shouldn't these be affected as well?

Mhm...Actually lowering the security level to 0 seems a little bit bad for a workaround. Any hints how to solve this?
...Thanks for your replies!

(In reply to Benjamin from comment #6)
> Mhm...Actually lowering the security level to 0 seems a little bit bad for a
> workaround. Any hints how to solve this?
> ...Thanks for your replies!

My second wild guess is that Qt and your browser use different configurations;
Chrome uses a different SSL library, for instance.  My third is that the
Nextcloud CalDAV server is using a really old certificate that could be upgraded,
but I'm way outside my knowledge.

(In reply to gjditchfield from comment #7)
> My second wild guess is that Qt and your browser use different
> configurations;
> Chrome uses a different SSL library, for instance.

that would explain why access via browser is possible.

>  My third is that the Nextcloud CalDAV server is using a really old certificate that could be
> upgraded, but I'm way outside my knowledge.

i doubt that's the issue, at least im running with let's encrypt certs. rather i suspect apache's TLS configuration could be causing this. can anyone suggest how to best debug this, e.g. getting some informative logs of the communication with the nextcloud server to get a hint what's going wrong? the server itself doesn't log any errors; it hardly logged anything, actually, as if it doesn't even get a request.

(In reply to m.eik michalke from comment #8)
> i doubt that's the issue, at least im running with let's encrypt certs.
> rather i suspect apache's TLS configuration could be causing this. can
> anyone suggest how to best debug this, e.g. getting some informative logs of
> the communication with the nextcloud server to get a hint what's going
> wrong? the server itself doesn't log any errors; it hardly logged anything,
> actually, as if it doesn't even get a request.

I think you could use wireshark-qt to spy on the communication.
I haven't found any hints about getting Qt to log more detail
about the connection;  maybe a Qt forum could help.

Okay I just tried a little bit around...

In this issue it is recommended to check the different openssl versions:
https://github.com/flathub/org.kde.kontact/issues/71
I then tried to upgrade the server of the nextcloud instance from openssl 1 to openssl 3. But still no success, the TLS connections cannot be resolved and the problem still exists...

Nextcloud is also upgraded to the latest release all other apps and working proberly.

I also think, that the issue described here might also be a problem:
https://syve.wordpress.com/2020/05/24/akonadi-bug-qlocalsocketconnecttoserver-invalid-name/

because the logs say:
>org.kde.pim.akonadicore: Socket error occurred: "QLocalSocket::connectToServer: Ungültiger Name"
>org.kde.pim.akonadicore: Socket error occurred: "Failed to connect to server!"
>org.kde.pim.akonadicore: Socket error occurred: "QLocalSocket::connectToServer: Ungültiger Name"
>org.kde.pim.akonadicore: Socket error occurred: "Failed to connect to server!"
>org.kde.pim.akonadicore: Socket error occurred: "QLocalSocket::connectToServer: Ungültiger Name"
>org.kde.pim.akonadicore: Socket error occurred: "Failed to connect to server!"
>org.kde.pim.akonadicore: Socket error occurred: "QLocalSocket::connectToServer: Ungültiger Name"
>org.kde.pim.akonadicore: Socket error occurred: "Failed to connect to server!"
>org.kde.pim.akonadicore: Akonadi Client Session: connection config file 'akonadi/akonadiconnectionrc' can not be found!
>org.kde.pim.akonadicore: "QLocalSocket::connectToServer: Ungültiger Name" "/home/benji/.var/app/org.kde.kontact/data/akonadiakonadiserver-ntf.socket"
org.kde.pim.akonadicore: Failed to connect to server!
org.kde.pim.akonadicore: Akonadi Client Session: connection config file 'akonadi/akonadiconnectionrc' can not be found!
org.kde.pim.akonadicore: "QLocalSocket::connectToServer: Ungültiger Name" "/home/benji/.var/app/org.kde.kontact/data/akonadiakonadiserver-ntf.socket"
org.kde.pim.akonadicore: Failed to connect to server!
QWidget::setLayout: Attempting to set QLayout "" on QGroupBox "", which already has a layout
kf.sonnet.clients.hunspell: Unable to find dictionary for "de_AT_frami" in path "/de_AT_frami"
kf.sonnet.clients.hunspell: Can't create a client without a speller
org.kde.pim.akonadicore: Akonadi Client Session: connection config file 'akonadi/akonadiconnectionrc' can not be found!
org.kde.pim.akonadicore: "QLocalSocket::connectToServer: Ungültiger Name" "/home/benji/.var/app/org.kde.kontact/data/akonadiakonadiserver-ntf.socket"
org.kde.pim.akonadicore: Failed to connect to server!
org.kde.pim.akonadicore: Akonadi Client Session: connection config file 'akonadi/akonadiconnectionrc' can not be found!
org.kde.pim.akonadicore: "QLocalSocket::connectToServer: Ungültiger Name" "/home/benji/.var/app/org.kde.kontact/data/akonadiakonadiserver-ntf.socket"

Here is also the akonadictl start output, cause I gues it might be useful:

>org.kde.pim.akonadiserver: Subscriber Akonadi::Server::NotificationSubscriber(0x7fd288049150) identified as "AgentBaseChangeRecorder - 94830632894288"
>qt.network.ssl: QSslSocket: cannot resolve OPENSSL_init_ssl
>qt.network.ssl: QSslSocket: cannot resolve OPENSSL_init_crypto
>qt.network.ssl: QSslSocket: cannot resolve ASN1_STRING_get0_data
>qt.network.ssl: QSslSocket: cannot resolve EVP_CIPHER_CTX_reset
>qt.network.ssl: QSslSocket: cannot resolve EVP_PKEY_up_ref
>qt.network.ssl: QSslSocket: cannot resolve EVP_PKEY_param_check
>qt.network.ssl: QSslSocket: cannot resolve RSA_bits
>qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_new_null
>qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_push
>qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_free
>qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_num
>qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_pop_free
>qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_value
>qt.network.ssl: QSslSocket: cannot resolve DH_get0_pqg
>qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_options
>qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_get_security_level
>qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_security_level
>qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_ciphersuites
>qt.network.ssl: QSslSocket: cannot resolve SSL_set_psk_use_session_callback
>qt.network.ssl: QSslSocket: cannot resolve SSL_SESSION_is_resumable
>qt.network.ssl: QSslSocket: cannot resolve SSL_get_client_random
>qt.network.ssl: QSslSocket: cannot resolve SSL_SESSION_get_master_key
>qt.network.ssl: QSslSocket: cannot resolve SSL_session_reused
>qt.network.ssl: QSslSocket: cannot resolve SSL_set_options
>qt.network.ssl: QSslSocket: cannot resolve TLS_method
>qt.network.ssl: QSslSocket: cannot resolve TLS_client_method
>qt.network.ssl: QSslSocket: cannot resolve TLS_server_method
>qt.network.ssl: QSslSocket: cannot resolve X509_up_ref
>qt.network.ssl: QSslSocket: cannot resolve X509_STORE_CTX_get0_chain
>qt.network.ssl: QSslSocket: cannot resolve X509_getm_notBefore
>qt.network.ssl: QSslSocket: cannot resolve X509_getm_notAfter
>qt.network.ssl: QSslSocket: cannot resolve X509_get_version
>qt.network.ssl: QSslSocket: cannot resolve X509_STORE_set_ex_data
>qt.network.ssl: QSslSocket: cannot resolve X509_STORE_get_ex_data
>qt.network.ssl: QSslSocket: cannot resolve OpenSSL_version_num
>qt.network.ssl: QSslSocket: cannot resolve OpenSSL_version
>qt.network.ssl: Incompatible version of OpenSSL
>qt.network.ssl: QSslSocket: cannot resolve OPENSSL_init_ssl
>qt.network.ssl: QSslSocket: cannot resolve OPENSSL_init_crypto
>qt.network.ssl: QSslSocket: cannot resolve ASN1_STRING_get0_data
>qt.network.ssl: QSslSocket: cannot resolve EVP_CIPHER_CTX_reset
>qt.network.ssl: QSslSocket: cannot resolve EVP_PKEY_up_ref
>qt.network.ssl: QSslSocket: cannot resolve EVP_PKEY_param_check
>qt.network.ssl: QSslSocket: cannot resolve RSA_bits
>qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_new_null
>qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_push
>qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_free
>qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_num
>qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_pop_free
>qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_value
>qt.network.ssl: QSslSocket: cannot resolve DH_get0_pqg
>qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_options
>qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_get_security_level
>qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_security_level
>qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_ciphersuites
>qt.network.ssl: QSslSocket: cannot resolve SSL_set_psk_use_session_callback
>qt.network.ssl: QSslSocket: cannot resolve SSL_SESSION_is_resumable
>qt.network.ssl: QSslSocket: cannot resolve SSL_get_client_random
>qt.network.ssl: QSslSocket: cannot resolve SSL_SESSION_get_master_key
>qt.network.ssl: QSslSocket: cannot resolve SSL_session_reused
>qt.network.ssl: QSslSocket: cannot resolve SSL_set_options
>qt.network.ssl: QSslSocket: cannot resolve TLS_method
>qt.network.ssl: QSslSocket: cannot resolve TLS_client_method
>qt.network.ssl: QSslSocket: cannot resolve TLS_server_method
>qt.network.ssl: QSslSocket: cannot resolve X509_up_ref
>qt.network.ssl: QSslSocket: cannot resolve X509_STORE_CTX_get0_chain
>qt.network.ssl: QSslSocket: cannot resolve X509_getm_notBefore
>qt.network.ssl: QSslSocket: cannot resolve X509_getm_notAfter
>qt.network.ssl: QSslSocket: cannot resolve X509_get_version
>qt.network.ssl: QSslSocket: cannot resolve X509_STORE_set_ex_data
>qt.network.ssl: QSslSocket: cannot resolve X509_STORE_get_ex_data
>qt.network.ssl: QSslSocket: cannot resolve OpenSSL_version_num
>qt.network.ssl: QSslSocket: cannot resolve OpenSSL_version
>qt.network.ssl: Incompatible version of OpenSSL
>qt.network.ssl: QSslSocket::startClientEncryption: TLS initialization failed
>qt.network.ssl: QSslSocket::startClientEncryption: TLS initialization failed
>org.kde.pim.davresource: Unable to fetch collections 300 "Bei der Abfrage ist ein Problem aufgetreten\nHTTP-Fehler (0)."
>qt.network.ssl: QSslSocket::startClientEncryption: TLS initialization failed
>qt.network.ssl: QSslSocket::startClientEncryption: TLS initialization failed
>org.kde.pim.davresource: Unable to fetch collections 300 "Bei der Abfrage ist ein Problem aufgetreten\nHTTP-Fehler (0)."

Okay i had success while running thourgh this issue:
https://stackoverflow.com/questions/52210603/qt-and-openssl-incompatible-version-on-ubuntu#52210604

That is definitely the problem here.

In my case the solution was easy. Just install libssl-dev:
>sudo apt install libssl-dev
did the trick. There are some symlinks missing or incompatibilities in qt networking and openssl...

glad you solved the problem on your side! however, installing libssl-dev didn't solve it for me, i'm still getting the "HTTP error (0)" response.

i checked with "akonadictl --verbose start" and don't see any errors regarding "qt.network.ssl", it just shows the HTTP error (0) without any further warnings or errors.

i also configured nextcloud to use log level 0 (debug, most verbose) and checked the logs: i don't even see a communication attempt, let alone any errors. there's also nothing logged by apache2.

after that, i installed vdirsyncer in my kubuntu 22.04 client and configured it to use the same auth data i was trying to use with kontact. it took quite a while, but i was able to discover and sync both calendars and contacts with vdirsyncer. also, i can see that in the nextcloud logs as expected.

any theories why kontact might noch even try to reach the nextcloud server? i am using a custom port (not 443) for HTTPS, is it possible that kontact/akonadi are ignoring it allthough it's given in the URL?

Not easy to say, but I would check the follwowing:
- Update nextcloud to the newest release
- Install openssl 3 on the server where the nc instance is running

on your desktop:
check out the issue i have posted above maybe there is a different solution to your problem.

...besides: I use backports ppa on my kubuntu to ensure that the newest packages are installed and updated...

This is all I can say sofar. 
But to be honest: I don't think that the problem is within nextcloud or serverside. It seems more a problem with akonadi/openssl/kontact (as this work together)...

regarding your question: no the port should not be a problem...port forwarding and stuff is handled by apache serverside so that is almost surely not a problem....

(In reply to Benjamin from comment #15)
> - Update nextcloud to the newest release
> - Install openssl 3 on the server where the nc instance is running

actually, i'm already running nextcloud 24 and the system also uses backports, so iguess that's not an issue.

i'm usually not a friend of replacing packages without some proof that that's actually the problem. so i was examining the TLS connection to the server in question using 'openssl s_client'. turns out: using a custom port an the server behind a NAT router might be the real issue in my case. at first 'openssl' kept waiting for a response until i aborted the call. i then tried the '-4' switch to force using an IPv4 address, and that resulted in a successful connection. TLS connection war ok for both TLS v1.2 and v1.3. this led me to assume that, while web browsers, the seafile client and vdirsyncer seem to fall back to IPv4 (because of the explicitly set port?), akonadi might only be trying IPv6 and doesn't get a response because there's not NAT.

> 
> on your desktop:
> check out the issue i have posted above maybe there is a different solution
> to your problem.
> 
> ...besides: I use backports ppa on my kubuntu to ensure that the newest
> packages are installed and updated...
> 
> This is all I can say sofar. 
> But to be honest: I don't think that the problem is within nextcloud or
> serverside. It seems more a problem with akonadi/openssl/kontact (as this
> work together)...

(In reply to m.eik michalke from comment #17)
> turns out: using a custom port
> an the server behind a NAT router might be the real issue in my case. at
> first 'openssl' kept waiting for a response until i aborted the call. i then
> tried the '-4' switch to force using an IPv4 address, and that resulted in a
> successful connection. TLS connection war ok for both TLS v1.2 and v1.3.
> this led me to assume that, while web browsers, the seafile client and
> vdirsyncer seem to fall back to IPv4 (because of the explicitly set port?),
> akonadi might only be trying IPv6 and doesn't get a response because there's
> not NAT.

yes, that's really it. i called 'ping -4' on the server and temporarily added it's current IPv4 address to /etc/hosts to resolve the domain locally, after that kontact was *instantly* able to fetch contacts and calendars. so all i'm missing is a way to tell kontact/akonadi to try IPv4 first.

(In reply to m.eik michalke from comment #18)
> after that kontact was *instantly* able to fetch contacts and calendars. so
> all i'm missing is a way to tell kontact/akonadi to try IPv4 first.

i've tried configuring the port forwarding for IPv6, but am still struggling with that (the router has an IPv6 address, but the server i'm trying to reach uses a local IPv4 address and is therefore only available via NAT and the router's IPv4 address). actually, i really think this should be considered a bug. there is a working network configuration via IPv4 that all other clients i tried are able to discover and use without any warnings or errors, only akonadi is now unable to do the same, alltough older versions are also perfectly fine with this setup. i'm ok with preferring IPv6 by default, but if that fails, kontact shouldn't simply give up but try IPv4 as well.

i configured /etc/gai.conf so that the system prefers IPv4 over IPv6 globally, but kontact seems to ignore this.

if i can't find any solution or at least a usable workaround for this problem, i'm stuck with kubuntu 20.04 on multiple machines, as i can't afford to break contacts and calendars on those, too.

I ran into this issue too, with the really not helpful `HTTP error (0)` error message.

It was working an a separate computer, same OS version, same original config (both were derived from the same OS image). So I did not believe it was a buggy version issue, something related to SSL, and so on.
Also, Nextcloud server did not receive any request (Nginx neither).


I have to thank you m.eik michalke for you tip : using `akonadictl --verbose start` I found out it raised a proxy error, and when I checked KDE system proxy setting, it was enable, with nothing configured except SOCKS.
Firefox and other browser did not have any issue - they ignore system proxy as far as I know.

It solved the issue with Korganiser. And a few other software actually, for instance Steam marketplace is working again (from inside Steam app).

So it's not the same issue as yours, so I'm not "resolving this bug" but I wanted to document my particular issue as it might help someone else to solve this…