IdP v4 SLO issues when wilcard certificates for websites

[Brent Putman]

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.

--Brent

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20200818/cc3d50b4/attachment.htm>