<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 10/24/16 11:48 AM, Cantor, Scott
wrote:</div>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A5CD18@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<pre wrap="">
This is the same as the typical case with metadata in fact, but I don't think we have any support at the moment for wiring in a simple certificate check for the TLS connection, just for the signature filter.</pre>
</blockquote>
<br>
That's probably true. Both of the existing HTTP metadata providers
(batch and dynamic) can take either a full TLSTrustEngine child
element, or a tlsTrustEngineRef to a bean, but I don't think we have
any shortcut for the single-certificate case. The easiest way I
can see would be via the ref, with a FactoryBean for
ExplicitKeyTrustEngine that we are discussing. I guess could also
add a certificate attribute somewhere or something, although that
means we then have 3 different ways to do the same thing, which
maybe starts to get a little confusing for the user...<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A5CD18@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite"><br>
<pre wrap="">
Yes, I've been aware of this one for a while, it's not a new thing, I just hadn't had the time to work up the wiring and actually test it. It's behaving like I'd expect with my metrics pusher. Default HttpClient wired in does "just trust the JVM and wave hands" and it fails on a self-signed cert. Adding a trust engine into the mix does the right thing based on how I configure it (and switching to the enhanced socket factory with no trust engine fails after the fact as you described).</pre>
</blockquote>
<br>
Awesome. I do like it when things actually work as designed. :-) <br>
<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A5CD18@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<pre wrap="">
I don't have example wiring at this point for PKIX via a custom root list though, which we probably need to work up. If you have something like that lying around...</pre>
</blockquote>
<br>
<br>
You're talking about "our" PKIX, i.e. via a PKIX TrustEngine? No, I
don't have anything. It's not unlike the explicit key one.
Basically a PKIXX509CredentialTrustEngine injected with a
StaticPKIXValidationInformationResolver that has the static
anchor(s) in it.<br>
<br>
But I thought we didn't want to promote PKIX anymore? Or is this
different, since we're talking about TLS, not XML signatures, etc.?<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A5CD18@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
</blockquote>
<br>
</body>
</html>