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@xxxxxxxxxx> 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/html/administration_guide/updating_the_tls_certificates_used_for_attribute_encryption
HTH,
Mark
>
> thanks,
>
--
389 Directory Server Development Team
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/389-users@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/389-users@xxxxxxxxxxxxxxxxxxxxxxx
