Attribute encryption issue

[Iain Morgan]

Hi,

,

Yesterday, I ran up against an attribute encryption issue, and I'm
looking for advice on how to debug and resolve the issue.

For background, I have a pair of RHEL 7 servers in an MMR configuration.
Let's call them host_A and host_B. Both are running the RedHat-provided
1.3.9 RPMs of 389-ds. There is also an RHEL 6 system, host_Z, that was
set up in an MMR configuration with host_B. This setup was used to test
the transition from one generation of servers to the next one.

All had dbeen working fine, and I next tried severing the connection
between host_Z and host_B. The replication agreements were removed and a
cleanAllRUV task was initiated on host_B. All seemed to go well -- until
I restarted host_A.

After restarting host_A, I got the following in the errors log:


[09/Jan/2020:17:00:36.191870707 -0800] - ERR - attrcrypt_unwrap_key - Failed to unwrap key
for cipher AES
[09/Jan/2020:17:00:36.192310924 -0800] - ERR - 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.
[09/Jan/2020:17:00:36.206041190 -0800] - ERR - attrcrypt_unwrap_key - Failed to unwrap key
for cipher 3DES
[09/Jan/2020:17:00:36.206478885 -0800] - ERR - 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.
[09/Jan/2020:17:00:36.206905949 -0800] - ERR - attrcrypt_init - All prepared ciphers are
not available. Please disable attribute encryption.


No change was made to the TLS certificate, and I would not have expected
the tear-down of the replication agreements between host_Z and host_b to
be relevant here. host_B is still able to replicate to host_A, but
host_A is unable to go in the other direction.

I haven't identified anything that would account for this problem. The
system had been up from early December and had not exhibited any issues.

So, any suggestions as to how I can troubleshoot and fix this issue? The
log messages don't seem to be very helpful.

thanks,

-- 
Iain Morgan

[Mark Reynolds]

On 1/10/20 6:48 PM, Iain Morgan wrote:
>  Hi,
>
>  ,
>
>  Yesterday, I ran up against an attribute encryption issue, and I'm
>  looking for advice on how to debug and resolve the issue.
>
>  For background, I have a pair of RHEL 7 servers in an MMR configuration.
>  Let's call them host_A and host_B. Both are running the RedHat-provided
>  1.3.9 RPMs of 389-ds. There is also an RHEL 6 system, host_Z, that was
>  set up in an MMR configuration with host_B. This setup was used to test
>  the transition from one generation of servers to the next one.
>
>  All had dbeen working fine, and I next tried severing the connection
>  between host_Z and host_B. The replication agreements were removed and a
>  cleanAllRUV task was initiated on host_B. All seemed to go well -- until
>  I restarted host_A.
>
>  After restarting host_A, I got the following in the errors log:
>
>
>  [09/Jan/2020:17:00:36.191870707 -0800] - ERR - attrcrypt_unwrap_key - Failed to unwrap
> key for cipher AES
>  [09/Jan/2020:17:00:36.192310924 -0800] - ERR - 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.
>  [09/Jan/2020:17:00:36.206041190 -0800] - ERR - attrcrypt_unwrap_key - Failed to unwrap
> key for cipher 3DES
>  [09/Jan/2020:17:00:36.206478885 -0800] - ERR - 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.
>  [09/Jan/2020:17:00:36.206905949 -0800] - ERR - attrcrypt_init - All prepared ciphers are
> not available. Please disable attribute encryption.
>
>
>  No change was made to the TLS certificate, and I would not have expected
>  the tear-down of the replication agreements between host_Z and host_b to
>  be relevant here. host_B is still able to replicate to host_A, but
>  host_A is unable to go in the other direction.
>
>  I haven't identified anything that would account for this problem. The
>  system had been up from early December and had not exhibited any issues.
>
>  So, any suggestions as to how I can troubleshoot and fix this issue? The
>  log messages don't seem to be very helpful. 
I can not explain why this has happened as replication and attribute 
encryption do not touch each other, but you can reset things by 
following the directions from the Admin guide here:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...

HTH,

Mark

>  thanks,
>  
-- 

389 Directory Server Development Team

[Alberto Viana]

Mark,

This is happens to me too, I think that is very easy to reproduce that.
Configure 389 to setup a self-signed certificate and enable TLS, after that
we import a new CA (we use a specific CA) and server-cert based on this new
CA. if I delete the self-signed cert (generated during the installation)
the 389 starts to show this error in log.

Seems that 389 works fine even with this error in log and I didn't try
anything to correct it.

Cheers,

Alberto Viana

On Fri, Jan 10, 2020 at 8:55 PM Mark Reynolds <mreynolds(a)redhat.com&gt; wrote:

>  On 1/10/20 6:48 PM, Iain Morgan wrote:
>  > Hi,
>  >
>  > ,
>  >
>  > Yesterday, I ran up against an attribute encryption issue, and I'm
>  > looking for advice on how to debug and resolve the issue.
>  >
>  > For background, I have a pair of RHEL 7 servers in an MMR configuration.
>  > Let's call them host_A and host_B. Both are running the RedHat-provided
>  > 1.3.9 RPMs of 389-ds. There is also an RHEL 6 system, host_Z, that was
>  > set up in an MMR configuration with host_B. This setup was used to test
>  > the transition from one generation of servers to the next one.
>  >
>  > All had dbeen working fine, and I next tried severing the connection
>  > between host_Z and host_B. The replication agreements were removed and a
>  > cleanAllRUV task was initiated on host_B. All seemed to go well -- until
>  > I restarted host_A.
>  >
>  > After restarting host_A, I got the following in the errors log:
>  >
>  >
>  > [09/Jan/2020:17:00:36.191870707 -0800] - ERR - attrcrypt_unwrap_key -
>  Failed to unwrap key for cipher AES
>  > [09/Jan/2020:17:00:36.192310924 -0800] - ERR - 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.
>  > [09/Jan/2020:17:00:36.206041190 -0800] - ERR - attrcrypt_unwrap_key -
>  Failed to unwrap key for cipher 3DES
>  > [09/Jan/2020:17:00:36.206478885 -0800] - ERR - 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.
>  > [09/Jan/2020:17:00:36.206905949 -0800] - ERR - attrcrypt_init - All
>  prepared ciphers are not available. Please disable attribute encryption.
>  >
>  >
>  > No change was made to the TLS certificate, and I would not have expected
>  > the tear-down of the replication agreements between host_Z and host_b to
>  > be relevant here. host_B is still able to replicate to host_A, but
>  > host_A is unable to go in the other direction.
>  >
>  > I haven't identified anything that would account for this problem. The
>  > system had been up from early December and had not exhibited any issues.
>  >
>  > So, any suggestions as to how I can troubleshoot and fix this issue? The
>  > log messages don't seem to be very helpful.
>
>  I can not explain why this has happened as replication and attribute
>  encryption do not touch each other, but you can reset things by
>  following the directions from the Admin guide here:
>
>
>
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...
>
>  HTH,
>
>  Mark
>
>  >
>  > thanks,
>  >
>  --
>
>  389 Directory Server Development Team
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]...
>

[William Brown]

This has been a known issue for some time.

https://pagure.io/389-ds-base/issue/49525



>  On 13 Jan 2020, at 22:37, Alberto Viana <albertocrj(a)gmail.com&gt;
> wrote:
>  
>  Mark,
>  
>  This is happens to me too, I think that is very easy to reproduce that. Configure 389 to
> setup a self-signed certificate and enable TLS, after that we import a new CA (we use a
> specific CA) and server-cert based on this new CA. if I delete the self-signed cert
> (generated during the installation) the 389 starts to show this error in log.
>  
>  Seems that 389 works fine even with this error in log and I didn't try anything to
> correct it.
>  
>  Cheers,
>  
>  Alberto Viana
>  
>  On Fri, Jan 10, 2020 at 8:55 PM Mark Reynolds <mreynolds(a)redhat.com&gt; wrote:
>  
>  On 1/10/20 6:48 PM, Iain Morgan wrote:
>  > Hi,
>  >
>  > ,
>  >
>  > Yesterday, I ran up against an attribute encryption issue, and I'm
>  > looking for advice on how to debug and resolve the issue.
>  >
>  > For background, I have a pair of RHEL 7 servers in an MMR configuration.
>  > Let's call them host_A and host_B. Both are running the RedHat-provided
>  > 1.3.9 RPMs of 389-ds. There is also an RHEL 6 system, host_Z, that was
>  > set up in an MMR configuration with host_B. This setup was used to test
>  > the transition from one generation of servers to the next one.
>  >
>  > All had dbeen working fine, and I next tried severing the connection
>  > between host_Z and host_B. The replication agreements were removed and a
>  > cleanAllRUV task was initiated on host_B. All seemed to go well -- until
>  > I restarted host_A.
>  >
>  > After restarting host_A, I got the following in the errors log:
>  >
>  >
>  > [09/Jan/2020:17:00:36.191870707 -0800] - ERR - attrcrypt_unwrap_key - Failed to
> unwrap key for cipher AES
>  > [09/Jan/2020:17:00:36.192310924 -0800] - ERR - 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.
>  > [09/Jan/2020:17:00:36.206041190 -0800] - ERR - attrcrypt_unwrap_key - Failed to
> unwrap key for cipher 3DES
>  > [09/Jan/2020:17:00:36.206478885 -0800] - ERR - 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.
>  > [09/Jan/2020:17:00:36.206905949 -0800] - ERR - attrcrypt_init - All prepared ciphers
> are not available. Please disable attribute encryption.
>  >
>  >
>  > No change was made to the TLS certificate, and I would not have expected
>  > the tear-down of the replication agreements between host_Z and host_b to
>  > be relevant here. host_B is still able to replicate to host_A, but
>  > host_A is unable to go in the other direction.
>  >
>  > I haven't identified anything that would account for this problem. The
>  > system had been up from early December and had not exhibited any issues.
>  >
>  > So, any suggestions as to how I can troubleshoot and fix this issue? The
>  > log messages don't seem to be very helpful.
>  
>  I can not explain why this has happened as replication and attribute 
>  encryption do not touch each other, but you can reset things by 
>  following the directions from the Admin guide here:
>  
>
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...
>  
>  HTH,
>  
>  Mark
>  
>  >
>  > thanks,
>  >
>  -- 
>  
>  389 Directory Server Development Team
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs