I still use the way mentioned in my post from almost 5 years ago. It gets overwritten from time to time, but I just re-run the commands to trust my cert again.

I think I changed .pem to .crt, but otherwise it is in /usr/share/ca-certificates/certificate.crt (filename doesn't really matter).

I don't know why are you getting the error, but I guess there is a problem with some certificate you put in there.

# make the root file system writable
sudo mount -o remount,rw /
# copy certificate
cp /home/.../nextcloud.pem /usr/share/ca-certificates
# run this command
dpkg-reconfigure ca-certificates

I tinkered around a little bit and moved the certificate between /usr/share/ca-certificates and /usr/share/ca-certificates/mozilla. I also renamed it "nextcloud.pem", "cert.pem" or "nextcloud.crt".

After the dpkg-reconfigure ca-certificates there is a question shown if I want to trust the new certificates. The answer-options are "yes", "no" and "ask". I ran the command multiple times. Sometimes I choose "yes", sometimes "ask". The next page shows a list with all the certificates. Unfortunatly the screen is croped and I can't read all the text. But I can select my new certificate.

I tryed navigating to https://192.168.x.x:1234 (my nextcloud instance) in the morph-browser to check if there is a warning about an untrusted certificate. Unfortunatly there still is. And additionally sudo dpkg-reconfigure ca-certificates now shows the error message /usr/sbin/dpkg-reconfigure: ca-certificates is broken or not fully installed and exits after the error.

I am not sure where I went wrong with my tinkering. Any Ideas of how to repair the damage in the sudo dpkg-reconfigure ca-certificates?

Is there a way to trust a certificate in UT? I found ths 4 years old thread:
https://forums.ubports.com/post/16216
Is there a better way of trusting a certificate by now? Or could I use a trusted certificate on my local server?

@zlamalp Did you have any trouble with your method of trusting the certificate of your nextcloud server?

Are there any known issues with CalDAV and https on UT?

Not specifically. But it is know that UT does not trust self signed certificates.

If I type http://192.168.x.x in my browser I get "Error: net::ERR_CONNECTION_REFUSED". https://192.168.x.x leads me to the nextcloud login page. So I think 192.168.x.x is my "base url". I now tried ownCloud, Nextcloud and Generic CalDAV with http://192.168.x.x and https://192.168.x.x. If I choose ownCloud or Nextcloud I get an error saying that the host-URL is invalid and I can't create the account at all. With Generic CalDAV I can create the account but the calender does not sync.

I synced my new phone with my old nextcloud server. I noticed that my old nextcloud server is reachable through http and https while my new one is only reachable via https. I am only in my local network so https is not that important. Are there any known issues with CalDAV and https on UT?

But I see another difference in the output.

host: https://owncloud.domain-name.eu
name: nextclouduser-name@owncloud.domain-name.eu

So I think you should only give the base url when you add the nextcloud account in accounts. Could this be your problem?

Oh, and I choose Owncloud, not generic. So that could be why these lines are different.

With the command account-console list I can find out the id of the currently existing account (28). If I type account-console show 28 into the terminal I get the following text:

account: id 28, enabled, provider: generic-caldav
Global settings:
/usr/bin/account-console:244: DeprecationWarning: Accounts.AccountSettingIter.next is deprecated
(ok, key, value) = iterator.next()
CredentialsId: 28 (<class 'int'>)
auth/mechanism: password (<class 'str'>)
auth/method: password (<class 'str'>)
enabled: True (<class 'bool'>)
host: http://192.168.x.x/remote.php/dav/calendars/"Nextloud-username"/"Calendar-name" (<class 'str'>)
name: "Nextcloud-username"@192.168.x.x/remote.php/dav/calendars/"Nextloud-username"/"Calendar-name" (<class 'str'>)

What does this deprecation warning mean?