Signature verification with Java 8

[Brent Putman]

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/20180914/08a43719/attachment.html>