CAS proxy validation failure - Configured TLS trust engine was not used

[Cantor, Scott]

On 8/17/20, 3:14 PM, "users on behalf of Paul B. Henson" <users-bounces at shibboleth.net on behalf of henson at cpp.edu> wrote:

>    Hmm, I think we are talking about different clients. I meant the idp was using the same httpclient both times, working
> the first time and failing the second. It sounds like you are talking about the CAS proxy client; in this test scenario, there
> is only one server acting as the proxy client, with only one certificate. I am reasonably confident that the proper
> certificate is being presented on every request, both the failed one and the successful one.

No, I meant what you meant. I assumed they were different CAS clients (i.e. servers, i.e. anybody that names a server a client deserves a wet fish slap).

>    Subsequent requests continue to fail with this error message:

It has to be completely broken then, and the error would suggest it's failing as a sanity check to prevent the code that's been put together incorrectly (not configuration, I mean how it's constructed inside) from accidentally failing open. So it's good that it's breaking.

The reason the "failing" call is logged is that the failure happens after the call is done, on the IdP side, by checking that the configured TrustEngine "did its work" and when it detects that it didn't, it knows that something bypassed the trust check internally and it fatally throws.

This prevents a mis-configured HttpClient from appearing to be enforcing a trust check from not realizing the check was never done.

So it's a canary that's revealing the bug.

>    Any thoughts off the top of your head what involving httpclients gets cached for 10 minutes? 

Connection pooling of some sort I would imagine.

I am not however seeing this kind of problem with my REST calls. I can't imagine what's different but possibly it's a bug somewhere in how the CAS beans are wired together.

-- Scott