Turning up logging for the IdP data sealer

[Wessel, Keith]

Thanks, Scott. And in fact, I'm seeing what I would expect in the logs. Maybe I'm missing something about keystores here.

What I have is two instances of the IdP. Each one has a cron job that checks our AWS secret manager secret every few minutes to see if it's changed. The actual key generation and value rotation is handled by a Lambda function.

If it has changed, the cron job pulls down the new value and adds it to a pkcs12 keystore using keytool's -importpass option. I can't remember now why I went with pkcs12 instead of jceks, but that shouldn't matter. But I'm wondering if this isn't what importpass is for. Does anyone have any insight on how to import a string into a secret key?

The IdP is finding the key with the right key alias in the keystore, but it's clearly a mismatched key for the key in the other IdP node.

Keith


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Monday, October 26, 2020 12:52 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Turning up logging for the IdP data sealer

On 10/26/20, 1:38 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:

>    I'd like a bit more visibility into what's leading up to this error. What class do I need to turn up logging for? Is it
> net.shibboleth.utilities.java.support.security.DataSealer? This seems like the logical choice based on what I see, but I've
> learned that it's not always what class to turn up based solely on the exception that's logged.

Should be, but you need TRACE to actually log any of the data. It's not going to show much, a tag error is an AEAD signal that the data has been tampered with. If not, then the key it loaded for a given alias is not the key that was used to encrypt it. The point of the rolling key version strings is to ensure that a given value always means the same key to every node so that should never happen.

-- Scott


-- 
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