-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XrdTpc curl nss/sssd strange interaction part 2 #1429
Comments
Update from the GGUS ticket -- when NSS iterates through the directory, if Since the CRLs are ignored anyway by the CA parsing code, there's a simple workaround to aggregate all the unique CAs into a directory and point XrdHTTP at that instead. This seems to be somewhat unique to the KEK CA. It's not clear why this is - but I'd note the KEK CA is a rare one without an intermediate CA. Certainly if it affected all CAs, we would have noticed this previously -- there's about a 50/50 chance this occurs as directory ordering is random. |
I think this has been solved, hasn't it? Can we close the issue? |
Agreed - this is fixed in the overhaul of the CA code in 5.2.0 for libcurl interactions. |
@abh3 - pinging on this ticket. I think this is definitely fixed up in 5.2.0 (and later, of course). |
Indeed, thanks for bringing this to me attention. This ticket can be closed. |
On the same topic, we have some disk nodes in EOSATLAS that have a hard time connecting to the DPM Tokyo site. We have two categories of disk nodes, some that work, some that fail. Again, all nodes have exactly the same configuration, certificates installed etc. These errors were reported by ATLAS since they were seeing 60% efficiency of the link between EOSATLAS and Tokyo.
A simple curl command from one the "offending" disk nodes shows the following fully reproducible error:
After debugging a bit, the issue seems to come from the CA authority which signed the Tokyo site certificate, namely KEK:
If I remove the revocation files (last two) the everything works fine. Needless to say, on other disk nodes where this error doesn't show up, the files are exactly the same with identical checksums.
For reference with the revocation files removed, we get:
I tried clearing the nss/sssd cache, but the error is still there. Only removing the link files fixes this problem. All the version of the packages are identical to the ones in ticket #1428
Any clue on what might be the issue here?
Thanks,
Elvin
The text was updated successfully, but these errors were encountered: