tls encryption and key changes: symmetric key failed to unwrap

[Jan Kowalsky]

Hi all,

we have the following situation: An 389ds with tls/ssl configured whith
an certificate from letsencrypt.

Since letsencrypt is short-dated we have an automated update routine for
regenerating the cert8.db.

Now we have this sort of errors in changelog.

[01/Jun/2018:11:46:40 +0200] attrcrypt - attrcrypt_unwrap_key: failed to
unwrap key for cipher AES
[01/Jun/2018:11:46:40 +0200] attrcrypt - attrcrypt_cipher_init:
symmetric key failed to unwrap with the private key; Cert might have
been renewed since the key is wrapped.  To recover the encrypted
contents, keep the wrapped symmetric key value.
[01/Jun/2018:11:46:40 +0200] attrcrypt - attrcrypt_unwrap_key: failed to
unwrap key for cipher 3DES
[01/Jun/2018:11:46:40 +0200] attrcrypt - attrcrypt_cipher_init:
symmetric key failed to unwrap with the private key; Cert might have
been renewed since the key is wrapped.  To recover the encrypted
contents, keep the wrapped symmetric key value.
[01/Jun/2018:11:46:40 +0200] attrcrypt - All prepared ciphers are not
available. Please disable attribute encryption.

I never used attribute encryption and we don't need it at the moment.
But as far as I understand, it's based on the server private key. This
is the one we change every 60 days.

The best idea seems to disable attribute encryption (which doesn't make
much sense if the private key isn't password protected anyway).

Or is there any other way to deal with key changes?

Thanks and regards
Jan

[Viktor Ashirov]

Hi,
On Fri, Jun 01 2018 at 12:06:50 +0200, Jan Kowalsky  wrote:
> Hi all,
>
> we have the following situation: An 389ds with tls/ssl configured whith
> an certificate from letsencrypt.
>
> Since letsencrypt is short-dated we have an automated update routine for
> regenerating the cert8.db.
>
> Now we have this sort of errors in changelog.
>
> [01/Jun/2018:11:46:40 +0200] attrcrypt - attrcrypt_unwrap_key: failed to
> unwrap key for cipher AES
> [01/Jun/2018:11:46:40 +0200] attrcrypt - attrcrypt_cipher_init:
> symmetric key failed to unwrap with the private key; Cert might have
> been renewed since the key is wrapped.  To recover the encrypted
> contents, keep the wrapped symmetric key value.
> [01/Jun/2018:11:46:40 +0200] attrcrypt - attrcrypt_unwrap_key: failed to
> unwrap key for cipher 3DES
> [01/Jun/2018:11:46:40 +0200] attrcrypt - attrcrypt_cipher_init:
> symmetric key failed to unwrap with the private key; Cert might have
> been renewed since the key is wrapped.  To recover the encrypted
> contents, keep the wrapped symmetric key value.
> [01/Jun/2018:11:46:40 +0200] attrcrypt - All prepared ciphers are not
> available. Please disable attribute encryption.
>
> I never used attribute encryption and we don't need it at the moment.
> But as far as I understand, it's based on the server private key. This
> is the one we change every 60 days.
>
> The best idea seems to disable attribute encryption (which doesn't make
> much sense if the private key isn't password protected anyway).
>
> Or is there any other way to deal with key changes?

It's possible to regenerate encryption keys from the new certificate:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ht...

HTH
> Thanks and regards
> Jan
> _______________________________________________
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....

[Jan Kowalsky]

Hi Viktor,

Thanks for the hint.
Am 01.06.2018 um 12:16 schrieb Viktor Ashirov:
> Hi,
> It's possible to regenerate encryption keys from the new certificate:
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ht...

I was already afraid, this is the only possibility. Nothing which I want
do every 60 days with about 50 databases and three replicated servers.

So probably disable encrypted attributes is the only way.

Dou you know if it's possible to disable encrypted attributes system
wide for all databases? Didn't find anything.

Thanks and regards
Jan

[Mark Reynolds]

On 06/01/2018 08:51 AM, Jan Kowalsky wrote:
> Hi Viktor,
>
> Thanks for the hint.
> Am 01.06.2018 um 12:16 schrieb Viktor Ashirov:
> > Hi,
> > It's possible to regenerate encryption keys from the new certificate:
> > https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ht...
>
> I was already afraid, this is the only possibility. Nothing which I want
> do every 60 days with about 50 databases and three replicated servers.

You have 50 backends on a single instance of DS?  <just curious>

Also, this is something you could script to make the task much easier, 
but...  These errors are harmless if you are not using attribute 
encryption.  So in your case you can just ignore the messages even 
though they are annoying & alarming.
> So probably disable encrypted attributes is the only way.
>
> Dou you know if it's possible to disable encrypted attributes system
> wide for all databases? Didn't find anything.

Feel free to file an RFE to disable it:

https://pagure.io/389-ds-base/new_issue
> Thanks and regards
> Jan
> _______________________________________________
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]....

[Jan Kowalsky]

Hi Mark,

Am 01.06.2018 um 15:24 schrieb Mark Reynolds:
> You have 50 backends on a single instance of DS?  <just curious>

It's a kolab Groupware with about 50 domains. This is the default setup
on kolab to have a backend for each domain. Maybe not ideal.... e.g. in
this case.
> Also, this is something you could script to make the task much easier,

Yes - but already the idea that every two month 50 databases are
reimported - shrinks me back. I'm not shure what happens with
replication in this situation and so on.
> but...  These errors are harmless if you are not using attribute
> encryption.  So in your case you can just ignore the messages even
> though they are annoying & alarming.

Once I got the situation - why ever - that I could't start dirsrv before
I delted the key entries. But it didn't happen again until yet. Maybe
the error was in fact somewhere else.

So: probably I'll ignore it.

Thanks and regards
Jan

[Zarko D]

Jan, have you resolve this? My 389ds fails to start now with same messages.