IdP v4 SLO issues when wilcard certificates for websites
putmanb at georgetown.edu
Wed Aug 19 00:25:53 UTC 2020
On 8/14/20 3:17 PM, Brent Putman wrote:
> On 8/14/20 12:50 PM, Cantor, Scott wrote:
>> For now, I've added a Logout Changes section to the 4.0 release notes and will update that section once I can do some research into the various points of control, including the certificate issue, but that won't be today. If there's a quick answer to that, Brent would have it, but otherwise I'll have to get into it next week.
> I'm off today, so I'll look at next week... But I thought the
> HttpClient hostname validation component we use actually did support
> wildcard certs. But need to double check.
Just to close the loop on this for the archives... Scott already
diagnosed the OP's actual problem here, which is not really about
hostname validation: metadata was not correct, so explicit key trust
eval was failing (and then falling into the PKIX trust engine, which
also fails b/c the metadata wasn't set up correctly for that either).
I confirmed that above statement: The HttpClient
DefaultHostnameVerifier used for HTTPS connections does support
wildcard certs for server TLS.
However the error message about the wildcard cert was not from that
layer, but rather from our BasicX509CredentialNameEvaluator, which is
used by our PKIX TrustEngines. It does not support wildcards in the
usual/expected way, but because of how those engines work it really
doesn't need to. If one needed to make that work (for some masochistic
reason), the way to do it would be to add explicit trusted names to the
metadata via ds:KeyName elements, just as you would for any domain
name(s) used by the entity ID and role. The non-obvious trick is that
for wildcard, you'd need to specify the cert's wildcard subject DN
value exactly as the KeyName value, with the '*' and so forth.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users