Signature verification with Java 8

[Goebel, Brent]

Hi Brent P.

Thanks very much for the feedback. Yes I'm seeing it logged at the ERROR level and everything seems to be working fine otherwise.

So I've probably seen this more lately because more authentication requests for this SP (or SPs) that have different length certificates. Since it's not my SP I'll just wait until they publish a new metadata file with (hopefully) new certificates that are the same length.

Thanks again for your expertise.

Brent

From: users <users-bounces at shibboleth.net> On Behalf Of Brent Putman
Sent: Friday, September 14, 2018 5:04 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Signature verification with Java 8




On 9/14/18 5:12 PM, Goebel, Brent wrote:
Hi all,

I've been getting a few of the signature verification errors (example below) lately and was wondering if anyone could provide insight about this error.

To be clear, are you just seeing this logged at level ERROR, and otherwise things are functioning normally?  That's what I would expect from reviewing the code.



I'm using Java 8 version 91. I did some research on the error and see a forum back in 2013 but at that provided some thoughts on what it may be from (exception when SP has multiple certs that have different lengths) but at the time was determined a bug that was fixed shortly after. Link to forum: http://shibboleth.1660669.n2.nabble.com/Signature-verification-exception-on-Java-7-td7584343.html.

That was similar in its root nature, but very different in end behavior, in that we weren't catching the error and allowing other credentials could be tried.  So if the first cred's cert key length was not equal to that of the signing key, the thrown exception was being propagated out and preventing the trust engine from trying the next cred with the "good" key.  That was fixed so that the exception is caught and the other credentials tried.  In this case, one would still see the ERROR level logging from SigningUtil b/c we can't distinguish this case from a "real" error.

So if you're just seeing the ERROR logging but otherwise everything is working fine, then that's what we would expect at this point.  It's not ideal but since we can't distinguish the exception cause, there's probably not much else we can do.

What would make this log output go away is either removing the "bad" credential from the SP's metadata, or re-ordering them so that the "good" cred appears in document order before the "bad" one.  If you're not in control of the SP's metadata then obviously you can't do that.  But if there are 2 SP signing certs because of an in-progress key rollover, then hopefully eventually the older "bad" one will be removed at some point by the metadata publisher.

Thanks,
(not the same) Brent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180917/a6fae753/attachment.html>