Linux desktop is SUSE Tumbleweed VERSION=ā20210801ā
SSL Labs: idp has b rating as forward secrecy is not active, owncloud server has the same, but HSTS is active with the recommended time limits (16000 i think)
This error msg appears upon connect of the OC client 2.8.1 for OIDC auth. The IDP server has a correct cert chain and LE certs, Nothing is self signed, see attachment of chain. The error message is simply misleading.
From what i know curl is a widely used tool and library which is reporting this message. As long as you are not facing a newly uncovered bug in this tool / library it should actually show a correct error message what curl is seeing.
I think there could be at least two reasons for this message:
Your system is too old that it doesnāt know the DST Root CA X3 or ISRG Root X1 certificates which are used to sign the LE certificate.
or
There is a DNS / setup problem and this message is caused because an unexpected server (e.g. a different server or similar) is tried for the connection which has a self signed certificate.
I know that curl is widely used, but this explanation is not really convincing.
The server is idp.netzwissen.de, IP 136.243.85.155 It is a freshly set up (in April 2021) VM with ubuntu 18.04 LTS which has all current patches. On the server there is an Univention UCS 5.0-0 errata59 which is also āup to dateā. So, we definitely have no āold software environmentā And why should there be a ādifferent server tried for connectionā, this makes no sense ā¦
Can someone direct me to location in the code from GitHub - owncloud/client: Desktop Syncing Client for ownCloud with the actual curl request used in this use case? I assume its from /oc-client/src/libsync/creds/oauth.cpp but where is the real curl call string?
i donāt think that the desktop client is using curl at all.
I think this message / connection is done on the ownCloud server and the curl installation on the UCS either sees one or more of the certificates in the chain (one of the both previously mentioned) as self signed or sees e.g. idp.netzwissen.de on e.g. 127.0.0.1 and tries to connect to itself but is arriving at a HTTP server having a self signed certificate configured.
ok, I couldnt find any curl calls in the client code. Then it would come form the openid app in the server. Therefore it is -maybe- an issue for Issues Ā· owncloud/openidconnect Ā· GitHub
I agree, I am also not shure yet if it is an āissueā of the oidc implementation of OC or a (mis-)config issue in the IDP/UCS. OIDC is great when it works, but not simple to set upā¦WiIl need some deeper analysis of the idp first ā¦
(info: the virtualisation uses KVM on proxmox, not docker)
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
if iām understanding the output correctly the curl call was done on the IDP server?
But i think the problem might not be on the IDP server (Ubuntu, running on KVM on proxmox) but on the ownCloud server (UCS, running oC in a docker container), that was the reason why i had suggested to run the curl commands in the docker container which is running oC.
The IDP (UCS with kopano for OIDC) runs in another KVM container than the OC server. Both are on the same proxmox host, but they have separate public IPs. The nslookup on the OC server shows: