Turning up logging for the IdP data sealer

[Wessel, Keith]

Scott,

By "artificially assign its own local name", no. My keytool call uses -alias to make the alias correspond with the value version from AWS secrets manager, and that's definitely there. In fact, the one IdP is finding a key in its data sealer store to use for encrypting the data sealer. The other node is also finding the key with that same alias, but it's got a different value. Is that what you mean by local name, or were you referring to something else?

I switched my script to jceks. I haven't tested it yet to see if it makes any difference with this, but I got a warning from it (albeit a picky one) that reminded me why I switched:

Warning: The JCEKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format

It then goes on to give me the -importkeystore syntax for doing that. I'm happy to try suppressing that warning and going with it if it'll help. But the question remains: if two different containers are both running keytool -importpass with the same input string and same alias, should they be able to both use the generated keystores to encrypt and decrypt one anothers' encrypted cookies?

Keith


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

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

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

Is your process maybe trying to artificially assign its own local name for the key or something rather than it being an intrinsic property of the key being imported?

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

Yes, that is the problem.

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