I'm going to throw this out there just as a possible clue. In my case, it had nothing to do with TLS or Jetty, but maybe it's related.
I have a system which signs request messages with a private key, and then checks that signature using the public key using vanilla java.security classes. Occasionally, I would get an inappropriate signature exception on validation on a legitimate message. Retrying the request, which would generate a new signature because the timestamp would change, would almost always succeed. Very occasionally I would have to retry a 3rd time. The method was to get the Signature of a defined set of headers, the set a signature header as BigInteger(Signature.byte[]).toString(). On the other side, it would be the reverse: signature header -> BigInteger -> Signature.byte[]. Occasionally the length of the byte[] array would be shorter than expected because leading zeros from the String header value would be dropped. The solution was to add the appropriate number of leading zeros to the byte array before validating the Signature. Apologies if this is just a distraction. - Linus On Thu, Aug 19, 2021 at 7:25 AM Daniel Wilkins <[email protected]> wrote: > Hi, I’ve been trying to track down a failure in using a TLS key on top of > Jetty. I had weird behavior on the app above so I downloaded standalone > jetty and tried it. This config seems to be minimal enough for me to see > what’s happening: > > --module=https > jetty.https.port=8443 > jetty.secure.port=8443 > jetty.keystore=etc/keystore > jetty.keystore.password=[secret value] > jetty.keystore.format=jks > > Everything else is the default settings in the start.ini file. I initially > tried using a truststore as well but it doesn’t get that far when it fails > to load the keystore. The key itself is just a password-protected 2048 bit > rsa key. I also tried converting the key to the pkcs12 format and jetty > started saying that the password was wrong, but that was just an aside; I’m > more than happy to get it to work with JKS. > > When I try to run it on the latest jetty 9.43 I get a trail of exceptions > which bottom out at this: > Caused by: javax.crypto.BadPaddingException: Given final block not > properly padded. Such issues can arise if a bad key is used during > decryption. > at com.sun.crypto.provider.CipherCore.unpad(CipherCore.java:975) > at > com.sun.crypto.provider.CipherCore.fillOutputBuffer(CipherCore.java:1056) > at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:853) > at > com.sun.crypto.provider.PKCS12PBECipherCore.implDoFinal(PKCS12PBECipherCore.java:405) > at > com.sun.crypto.provider.PKCS12PBECipherCore$PBEWithSHA1AndDESede.engineDoFinal(PKCS12PBECipherCore.java:437) > at javax.crypto.Cipher.doFinal(Cipher.java:2168) > at sun.security.pkcs12.PKCS12KeyStore.engineGetKey(PKCS12KeyStore.java:371) > ... 33 more > > The error message hints at this being caused by a bad key, but I’m able to > view/manipulate the key in key tool as well as Keystore Explorer. This key > is also used without any problems in other services of ours which don’t use > Jetty. > > Does anyone have a clue what might be going on here? I know that the > errors don’t appear to come from jetty itself, but I feel like it has to be > involved somewhere considering how keytools, keystore explorer, and other > java services seem to be able to load it. > > Thanks. > _______________________________________________ > jetty-users mailing list > [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users > -- Linus Kamb ------------------------------------------ NOAA / PMEL + UW / CICOES office: 206.526.4356 cell: 206.795.7934
_______________________________________________ jetty-users mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
