Closed vrbanecd closed 2 weeks ago
As the error indicates there has been a problem with the ssl/tls when communicating with the OP.
Please make sure that the OP's cert is valid and that you can http from the relevant machine to that OP, e.g. through a browser, but also using curl
.
It might be necessary to update the system certificates
As the error indicates there has been a problem with the ssl/tls when communicating with the OP.
Just to point out that the message Error: error with ssl cert
provides no information on what is the nature of the problem: has the certificate expired? Is the hostname not mentioned in the certificate's SubjectAltName? Is the cert chain missing some intermediate CA? Is the CA simply not trusted? ...etc...
This would be useful information.
Also, in the case of TLS problems, it might be useful to know the DN of the server-supplied certificate (or list the certificate chain, if multiple certs were provided).
Please make sure that the OP's cert is valid
How?
that you can http from the relevant machine to that OP, e.g. through a browser,
The OIDC endpoint, when entered in the browser, shows no problems (Dijana forgot to mention this).
However, I'm not sure checking with a browser is such a strong diagnostic tool. A browser might have a different trust store, apply different validity rules on certificates (e.g., ignoring CRLs), etc. It's very likely an expired certificate would be caught this way, but since the endpoint works in the browser, I'm not sure it helps us much.
but also using curl
Which curl command would you recommend?
As the error indicates there has been a problem with the ssl/tls when communicating with the OP.
Just to point out that the message
Error: error with ssl cert
provides no information on what is the nature of the problem: has the certificate expired? Is the hostname not mentioned in the certificate's SubjectAltName? Is the cert chain missing some intermediate CA? Is the CA simply not trusted? ...etc...This would be useful information.
It's true that we summarize a range of different problem causes under a general SSL error.
Additional information, indicating the problem cause, should be available in the log file (/var/log/auth.log
). One can grep/search for HTTP Request failed
.
Also, in the case of TLS problems, it might be useful to know the DN of the server-supplied certificate (or list the certificate chain, if multiple certs were provided).
I'm afraid that this information is (at least not straightforward) available from libcurl.
Please make sure that the OP's cert is valid
How?
that you can http from the relevant machine to that OP, e.g. through a browser,
The OIDC endpoint, when entered in the browser, shows no problems (Dijana forgot to mention this).
However, I'm not sure checking with a browser is such a strong diagnostic tool. A browser might have a different trust store, apply different validity rules on certificates (e.g., ignoring CRLs), etc. It's very likely an expired certificate would be caught this way, but since the endpoint works in the browser, I'm not sure it helps us much.
It's true, that this is only a very rudiment first-try to rule out that there is actually something wrong with the cert. If this works, from my experience, it usually means that the certificate is just not found in the trust store.
but also using curl
Which curl command would you recommend?
A simple curl <issuer>/.well-known/openid-configuration
should be enough to indicate if curl also has the same ssl error or not.
My guess would be that updating the system's trust store, e.g. updating the ca-certificates
would do the trick.
Is the issuer in question https://wlcg.cloud.cnaf.infn.it/ ?
I encounter some cert problems there.
Hi! The issuer is https://iam-ildg.cloud.cnaf.infn.it/.
Thanks, I get the same error for both of these OPs:
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
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.
This is not related to oidc-agent. It's more likely to be a problem with the certificate (chain) on the servers.
Great, I get the same error.
Is there any other information about this that I can provide you with?
I contacted Francesco at cnaf about it, we will see.
OK, great, thanks!
Just a quick update
The server is sending only the EEC, which is signed by GEANT OV. This (intermediate) CA is not part of CA/B, so not trusted. Including the GEANT OV in the cert chain would fix this, as the GEANT OV certificate is signed by USERTRUST, which is part of the CA/B.
Also, it looks like the EEC was recently replaced (likely 2024-10-30), which is consistent with Dijana's observation that it stopped working rather recently.
This leaves open the question why Firefox was accepting this EEC. Perhaps somehow caching the GEANT OV certificate, so omitting the intermediate CA didn't trigger a problem.
The error has been resolved at CNAF.
When adding a previously configured account in oidc-agent, I get a an error:
This account configuration was previously working fine.
I don't understand what is this error message trying to tell me, nor how to go about fixing it.
Adding any other previously configured account is working fine.