error:0A000152:SSL routines::unsafe legacy renegotiation disabled with Shibboleth SP 3.4
ndk at signet.id
Thu Nov 10 23:54:25 UTC 2022
A working installation of 3.3 on Windows 2019 that was upgraded to 3.4 is suddenly experiencing failure to connect to 4 hosts that are providing their metadata through URL-based resolution. No configuration nor environmental changes occurred other than the upgrade of the SP. Upon startup:
2022-11-10 18:10:25 ERROR XMLTooling.libcurl.InputStream : error while fetching https://redacted1/idp/shibboleth: (35) error:0A000152:SSL routines::unsafe legacy renegotiation disabled
2022-11-10 18:10:25 ERROR XMLTooling.ParserPool : fatal error on line 0, column 0, message: internal error in NetAccessor
2022-11-10 18:10:25 ERROR OpenSAML.MetadataProvider.XML : error while loading resource (https://redacted1/idp/shibboleth): XML error(s) during parsing, check log for specifics
2022-11-10 18:10:25 WARN OpenSAML.MetadataProvider.XML : adjusted reload interval to 600 seconds
2022-11-10 18:10:25 WARN OpenSAML.MetadataProvider.XML : trying backup file, exception loading remote resource: XML error(s) during parsing, check log for specifics
Checking the affected hosts, it appears that:
1) Three of them do not support secure renegotiation,
2) None has insecure negotiation enabled,
3) Interestingly, one of them *does* support secure renegotiation.
Three of them support TLS 1.0/1.1, including the one that supports secure renegotiation.
To further debug the issue, we attempted adding the configuration:
<TransportOption provider="OpenSSL" option="SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION">1</TransportOption>
This made no apparent difference: connection still failed to these four hosts.
Since the configuration change made no difference and one of the hosts does support secure renegotiation, it smells to me like the error message is spurious, but I can't see any obvious commonality among the hosts.
Is anyone else experiencing this?
Thanks in advance,
The Art of Access ®
More information about the users