[JIRA] (OSJ-379) "trustAnchors parameter must be non-empty" failure in httpClient

[Brent Putman (Jira)]

Brent Putman ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A97de0981-adc3-4044-95ed-131622fad81e ) *commented* on OSJ-379 ( https://shibboleth.atlassian.net/browse/OSJ-379?atlOrigin=eyJpIjoiMDcxZjQ4ODllNjJjNDFjM2FlZjJmZjBmYmYwMzQ2NWYiLCJwIjoiaiJ9 )

Re: "trustAnchors parameter must be non-empty" failure in httpClient ( https://shibboleth.atlassian.net/browse/OSJ-379?atlOrigin=eyJpIjoiMDcxZjQ4ODllNjJjNDFjM2FlZjJmZjBmYmYwMzQ2NWYiLCJwIjoiaiJ9 )

Well, some googling shows that the error itself is common. But no info so far on it working most of the time but failing a small percentage.

Note that the trust store it’s using is going to be one of these, in this order:

   $JAVA_HOME/lib/security/jssecacerts
   $JAVA_HOME/lib/security/cacerts

unless overridden with a system property: -Djavax.net.ssl.trustStore

One would think they would read in the trust store once and cache it or something unless/until it changes. But if not, and if they are reading it on every TLS validation, then the obvious question is: Is something preventing it from being able to read the trust store file sometimes but not others? Like is it on a remote filesystem or something else unstable? High file I/O or contention? Perms eval that could fail randomly? Other localized environmental issues that I can’t speculate on?

As Scott said, ideally in OpenSAML/IdP you don’t want to use the standard Java TLS/PKIX stuff. Since this is MDQ and the metadata is signed and you’re configuring to validate that XML signature, there’s no real reason to care about the TLS trust layer. So setting disregardTLSCertificate would be fine. Or alternately, configuring to trust the MDQ server using our trust engine stuff, either explicit key, or PKIX if you really want to.

( https://shibboleth.atlassian.net/browse/OSJ-379#add-comment?atlOrigin=eyJpIjoiMDcxZjQ4ODllNjJjNDFjM2FlZjJmZjBmYmYwMzQ2NWYiLCJwIjoiaiJ9 ) Add Comment ( https://shibboleth.atlassian.net/browse/OSJ-379#add-comment?atlOrigin=eyJpIjoiMDcxZjQ4ODllNjJjNDFjM2FlZjJmZjBmYmYwMzQ2NWYiLCJwIjoiaiJ9 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core&referrer=utm_source%3DNotificationLink%26utm_medium%3DEmail ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailNotificationLink&mt=8 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100225- sha1:d57183e )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/commits/attachments/20230518/a9c214aa/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-comment-icon-c75a578d-c275-4901-9664-2d6606339f00
Type: image/png
Size: 1084 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20230518/a9c214aa/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-avatar-3ca006db-e2e6-475c-bff5-40724423173d
Type: image/png
Size: 345 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20230518/a9c214aa/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-footer-desktop-logo-cc531692-002f-41a0-b395-1d4d2b6b9eb0
Type: image/png
Size: 10805 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20230518/a9c214aa/attachment-0005.png>