<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body>

    <p><br>

    </p>

    <div class="moz-cite-prefix">On 8/14/20 3:17 PM, Brent Putman wrote:<br>

    </div>

    <blockquote type="cite"

      cite="mid:bdb0ef71-8a67-2ebd-474b-ada12d07b25b@georgetown.edu">

      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

      <p><br>

      </p>

      <div class="moz-cite-prefix">On 8/14/20 12:50 PM, Cantor, Scott

        wrote:<br>

      </div>

      <blockquote type="cite"

        cite="mid:9FC905A8-68AC-4F38-9F57-91660005135C@osu.edu">

        <pre class="moz-quote-pre" wrap="">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.

</pre>

      </blockquote>

      <p><br>

      </p>

      <p>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. </p>

    </blockquote>

    <p><br>

    </p>

    <p>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).</p>

    <p>I confirmed that above statement: The HttpClient

      DefaultHostnameVerifier used for HTTPS connections does support

      wildcard certs for server TLS.</p>

    <p>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.</p>

    <p>--Brent<br>

    </p>

  </body>

</html>