IdP v4 SLO issues when wilcard certificates for websites

Lipscomb, Gary glipscomb at
Mon Aug 17 22:56:51 UTC 2020

Hi Scott,

Is there anything that I can provide to assist in troubleshooting this case?
The SP's in question are internal ones

RHEL 7.8
Shibboleth SP 3.1.0
Tomcat 7


-----Original Message-----
From: users <users-bounces at> On Behalf Of Cantor, Scott
Sent: Tuesday, 18 August 2020 04:14
To: Shib Users <users at>
Subject: Re: IdP v4 SLO issues when wilcard certificates for websites

Actually, to be more clear about this, my point is really that I'm close to certain this is not failing in the way that the error message is leading one to believe.

> Perhaps the real problem here is in fact a trust error. If the right cert isn't in the metadata and more to the point if the
> SP is not up to date and not signing its response, it's not going to work.

Basically, this is just flushing out bad metadata, and that's inevitable.

The failure isn't because the endpoint has a wildcard certificate, it's because the SOAP exchange isn't authenticated with a signature or TLS certificate that's trusted.

The way that manifests for an upgraded system is that the PKIX engine is still in there wasting people's time, and it’s failing through the normal direct compare and trying to validate the certificate. Before it bothers, it does the trusted name check, and the only valid trusted name in that case is the SP entityID. Doesn't matter that it's a wildcard, it's just logging that because it's what happens to be there.

With a fresh install, V4 doesn't do PKIX by default so you'd get the more usual errors resulting from the inline trust engine failing.

That's my guess anyway.

If the SP were anything remotely recent, it should be auto-signing the SOAP logout response from a port 443 exchange using its normal signing key. So there's that detail too.

-- Scott

For Consortium Member technical support, see
To unsubscribe from this list send an email to users-unsubscribe at

More information about the users mailing list