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

[Paul B. Henson]

> From: Cantor, Scott
> Sent: Monday, August 17, 2020 4:27 PM
> 
> I don't either, and I reviewed the code, and it looks fine to me. I don't see any
> way this could be happening.

I seem to be very good at finding that kind of bug 8-/.

> I think there's an issue that's preventing the HTTP stack from properly invoking
> the hooks that allow the trust check to happen. And I don't think we can rule out
> platform issues but I don't know if you said what the details are.

I hadn't mentioned them yet, but this should be a pretty supportable platform; it's just stock CentOS 8 with the bundled OpenJDK 11 and the latest version of jetty.

> There isn't much to do but file it with all the specifics.

Done, IDP-1657. I've got an environment set up right now to compile the idp (at first I thought I broke something with my CAS PGT encoding patch, but it still occurs with the out-of-the-box WAR), any suggestions at what to poke at to try and figure this out?

I've been looking at HttpClientProxyValidator.java, this seems to be the relevant piece:

            response = httpClient.execute(request, clientContext);
            HttpClientSecuritySupport.checkTLSCredentialEvaluated(clientContext, request.getURI().getScheme());
            return response.getStatusLine().getStatusCode();
[...]
        } catch (final SSLPeerUnverifiedException e) {
            throw new CredentialException("Untrusted certificate presented by CAS proxy callback endpoint");

When it works, it returns 200. When it doesn't, the call to checkTLSCredentialEvaluated throws an exception. Both calls seem to be using the same instance of the httpClient and securityParameters. Those don't seem to explicitly define the certificate to be trusted though? Where does the certificate defined in the metadata for that relying party get stuffed into the httpclient as the one that needs to be found?