The problem does not manifest on other (non linux) devices.

confirming

Can you provide more information. What servers are to accessing that you cannot connect with, or what cert chains are being rejected?

There was a recent update to ca-certificates to match it up with mozilla. Some certs were removed or restricted, but it could also be a collision with the signing certificates. To fix (or verify the change was intentional) we'd need the actual CA cert that's missing. The Certificate change or the server would tell us that information.

Thanks,
bob

Cannot reproduce, please provide more details.

In my testing, I had:
1. ca-certificates-2023.2.60_v7.0.306-1.0.fc38
2. google account with one contact added (verified through contacts.gmail.com)
3. said google account added in GOA through gnome-settings

I've
1. installed evolution-3.48.4-1.fc38.x86_64 (never had it installed before on this machine)
2. launched evolution

I've observed
1. evolution to launch and immediately start downloading email from gmail
2. "To Do" list on the right started populating with calendar events
3. under the Contacts tab, I see the google address book, clicking on it shows me a card with the one contact I have

Menu - Accounts - unfold GOA account - unfold Address Books - Address Book - Edit
reveals the URL to be
https://www.googleapis.com/carddav/v1/principals/$ACCOUNT_NAME/lists/default/
That by itself also doesn't help me reproduce the failure, as
`gnutls-cli --ca-verification www.googleapis.com:443` and
`openssl s_client www.googleapis.com:443` seem to connect just fine
(I'll attach the logs).

Please share all the relevant customizations one needs to reproduce the failure
and explicitly post the (possibly redacted) URL you're using for CardDaV.
Without that, I'm afraid I don't know how to untangle your problem.

Created attachment 1993117 [details]
logs for connecting to www.googleapis.com with gnutls

Created attachment 1993118 [details]
logs for connecting to www.googleapis.com with openssl

The problems seems to be resolved for me after an update today.
I think this update fixed the issue for me:
    Upgrade  ca-certificates-2023.2.60_v7.0.306-1.0.fc38.noarch @updates
    Upgraded ca-certificates-2023.2.60-2.fc38.noarch            @@System

But that's a downgrade, so it means the problem is not solved:

$ rpmdev-vercmp 2023.2.60-2.fc38 2023.2.60_v7.0.306-1.0.fc38
2023.2.60-2.fc38 < 2023.2.60_v7.0.306-1.0.fc38

In bz1850512#c40 it was suggested that there might be problems
if one updates ca-certificates without restarting evolution.
Does restarting evolution help?

Also, bears repeating, please post URLs you use
from Menu - Accounts - <problematic address book> - Edit,
at least up to and including the domain part of them.
It's the single most important starting piece of the puzzle here.

I did for sure not intentionally downgrade. Actually I also am pretty sure no downgrade was done.

# dnf list installed | grep -i ca-certificates
ca-certificates.noarch                             2023.2.60_v7.0.306-1.0.fc38         @updates

It could very well be the case that the issue was caused by updates without restarting evolution. Actually, now I think this was the root cause of the issue.

I use a self hosted Nextcloud with Let's Encrypt certificates, and a Microsoft Exchange account configured in GNOME Online Accounts.

I'm going to assume this is the same issue as bug 1850512. If that turns out to be wrong Jan, feel free to reopen this bug.

*** This bug has been marked as a duplicate of bug 1850512 ***

Giving a dummy reply to eliminate my "needs info" request...