Page Comparison

...

Unsurprisingly, the "explicit" engine is a lot bit simpler to use. You can provide any number of public keys and certificates via resources (file, classpath, even HTTP, though that gets pretty circular here), to drive the engine.

...

<bean id="CustomHttpSecurity" class="org.opensaml.security.httpclient.HttpClientSecurityParameters">
	<property name="tLSTrustEngine">
		<bean parent="shibboleth.StaticExplicitTrustEngine">
			<property name="publicKeys">
				<list>
					<value>%{idp.home}/credentials/pubkey1.pem</value>
					<value>%{idp.home}/credentials/pubkey2.pem</value>
				</list>
			</property>
		</bean>
	</property>
</bean>

<!-- Sample feature we're actually trying to use, which we inject custom rules into. -->
<bean id="PushReporter" parent="shibboleth.metrics.HTTPReporter" c:name="MyCollector"
	p:httpClient-ref="CustomHttpClient"
	p:httpClientSecurityParameters-ref="CustomHttpSecurity"
	p:collectorURL="https://log.example.org/cgi-bin/collector.cgi" />

Applying a TrustEngine

You should always start by configuring a component using the HttpClient with the HttpClientSecurityParameters The full range of PKIX options is quite complex, but for basic use cases a factory bean makes it simple. To validate the server's certificate against a fixed CA (name checking is turned off because the HttpClient is already doing this step):

<bean id="CustomHttpSecurity" class="org.opensaml.security.httpclient.HttpClientSecurityParameters">
	<property name="tLSTrustEngine">
		<bean parent="shibboleth.StaticPKIXTrustEngine"
			p:certificates="%{idp.home}/credentials/rootca.pem"
			p:checkNames="false" />
	</property>
</bean>

<!-- Sample feature we're actually trying to use, which we inject custom rules into. -->
<bean id="PushReporter" parent="shibboleth.metrics.HTTPReporter" c:name="MyCollector"
	p:httpClient-ref="CustomHttpClient"
	p:httpClientSecurityParameters-ref="CustomHttpSecurity"
	p:collectorURL="https://log.example.org/cgi-bin/collector.cgi" />

Other PKIX options include the verifyDepth property to control the chain length, and the cRLs property to supply certificate revocation lists.

Applying a TrustEngine to HttpClient

You should always start by configuring a component using the HttpClient with the HttpClientSecurityParameters wiring needed to implement your needs, as in the above examples, then .

Once that's in place, temporarily configure the HttpClient with the connectionDisregardTLSCertificate flag on, and finally just test it and let it fail and log something like the following:

...