I made a new patch that does not add the new --notls option to disable TLS altogether. However, with that patch, if the CA directory exists, but has no certificates, the client will think it is able to use TLS and fail even when passing --notlsok to it, as the TLS context can be initialized, but the client has no certificates to verify any servers. In this case, we'd be back to not being able to connect at all if ztn is enabled on the server. Maybe it's worth specifying ahead of time how the client should behave on each case in which TLS is not working, then I will see a good way to get that behavior to work. Ideally, I would like to find a way to fallback to non-TLS only when needed, and be able to recover also when the CA directory exists, but verification of the server fails (so that authentication can fallback from ztn to kerberos, etc, when --notlsok option is used).

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/xrootd/xrootd/pull/2031#issuecomment-1589246786", "url": "https://github.com/xrootd/xrootd/pull/2031#issuecomment-1589246786", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1