Signature verification with Java 8

[Jacob Lundberg]

Hi Brent,

It sounds like your problem is different, but just to add some additional color...  We see that error very sporadically on just one member of our IdP cluster.  The value of the "got X" field is all over the place.  We can reproduce using our load testing framework.  In our case, when the error triggers, the login usually fails.  However, we have always assumed the problem must be in hardware because the other cluster members do not generate the error (so, we've never asked about the problem here).  Swapping out the server hardware also seems to resolve it, but we never load tested that configuration.  An image of the container from a server that works reliably will misbehave sporadically on the "funky" server.  However, the server exhibits no other problems running the IdP or anything else.  It's such a bizarre error...  Ultimately our plan is to punt on this and move it to another server.

-Jacob

-- 

Jacob Lundberg
AVP, IT Architecture
503.290.0100 (voice)
503.973.5252 (fax)

-----"users" <users-bounces at shibboleth.net> wrote: -----
To: "Shib Users" <users at shibboleth.net>
From: "Goebel, Brent" 
Sent by: "users" 
Date: 09/17/2018 12:43PM
Subject: RE: Signature verification with Java 8

       
 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
    
-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net