Hi Pierre,

Thanks for the clarification. FWIW, I haven't experienced any issues with 
replication agreement credentials post rolling of keys, but we've been running 
1.3 and are just now migrating to 1.4, so may need to keep an eye on that.

Do you think it would it be feasible to have those attribute encryption keys 
based on a different RSA key? I could raise a feature request. The way the 
world has been heading with certs is to make them shorter, shorter, shorter. 
Ordinarily, that's not a bad thing because we can use config management to 
automatically roll certs as required, but have found the process with NSS to be 
quite cumbersome. The RH doco on the subject (RHDS 11 admin guide) involves a 
complete new key every time it is renewed, but there's no mention of care 
around attribute encryption (that's an issue for the RH doco team) - 
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/managing_the_nss_database_used_by_directory_server#renewing_a_certificate.<https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/managing_the_nss_database_used_by_directory_server#renewing_a_certificate>


If I were using attribute encryption, i think i would just keep re-using the 
original CSR to issue a new cert and replace that rather than rolling the key 
each time, but I believe that's considered bad practice these days too. A 
separate rsa key would be ideal IMO.


Cheers,
Grant


On Fri, 2021-11-26 at 13:48 +0100, Pierre Rogier wrote:

[External Mail]

Hi Grant,

I think that you are absolutely right here:
  I suspect that the "Please disable encryption" is misleading
    as according to the code, the only way not to initialize the
     attribute encryption keys is to fully disable the security.
  So removing the attribute encryption key entry is probably the only thing to 
do. (possible because no encrypted attributes are configured)

That said there is another point that could cause problems with cert renewal: 
the replication agreement credential is also using symmetrical encryption so 
you may have to replace their passwords.

Regards
   Pierre

On Fri, Nov 26, 2021 at 2:35 AM Grant Byers 
<[email protected]<mailto:[email protected]>> wrote:
Hi all,


Is there a way to either permanently disable attribute encryption, or to have 
the symmetric keys generated from an alternate RSA private key to that used for
TLS (given by cn=RSA,cn=encryption,cn=config)? I may be missing something, but 
this seems to be completely tied to TLS.


We don't use attribute encryption at all presently, and the process we use for 
rolling certtificates is basically a re-key. This results in the following error
messages;


[25/Nov/2021:06:32:33.562508644 +0000] - ERR - attrcrypt_unwrap_key - Failed to 
unwrap key for cipher AES
[25/Nov/2021:06:32:33.564813203 +0000] - 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.
[25/Nov/2021:06:32:33.931422579 +0000] - ERR - attrcrypt_unwrap_key - Failed to 
unwrap key for cipher 3DES
[25/Nov/2021:06:32:33.935241033 +0000] - 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.
[25/Nov/2021:06:32:33.937228742 +0000] - ERR - attrcrypt_init - All prepared 
ciphers are not available. Please disable attribute encryption.


I realise we could delete the encrypted attribute keys entries as part of our 
renewal process & have them regenerated, but that seems pretty hackish. The
message implies attribute encryption can be disabled ("Please disable attribute 
encryption."), yet the only way I see to do this is to disable TLS via nsslapd-
security. Can someone confirm?


Thanks,
Grant

_______________________________________________
389-users mailing list -- 
[email protected]<mailto:[email protected]>
To unsubscribe send an email to 
[email protected]<mailto:[email protected]>
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2F&data=04%7C01%7Cgrant.byers%40aarnet.edu.au%7C8506a06c7aa848a455a808d9b0db31fd%7C4795f4d0a4b847c4af198dd47da5d8d4%7C0%7C0%7C637735277785356961%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2F93YS7vRUygCl6uOytRCzDHVCFCpFKhqeTIggQNVF50%3D&reserved=0>
List Guidelines: 
https://fedoraproject.org/wiki/Mailing_list_guidelines<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelines&data=04%7C01%7Cgrant.byers%40aarnet.edu.au%7C8506a06c7aa848a455a808d9b0db31fd%7C4795f4d0a4b847c4af198dd47da5d8d4%7C0%7C0%7C637735277785356961%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yRKfiXq7dk2BY08HbpIDz9NMX%2Fv3TNnuCWCwwj23ns4%3D&reserved=0>
List Archives: 
https://lists.fedoraproject.org/archives/list/[email protected]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedoraproject.org%2Farchives%2Flist%2F389-users%40lists.fedoraproject.org&data=04%7C01%7Cgrant.byers%40aarnet.edu.au%7C8506a06c7aa848a455a808d9b0db31fd%7C4795f4d0a4b847c4af198dd47da5d8d4%7C0%7C0%7C637735277785366955%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=esiaVS50oEa1pdw29vHZ0JedRKFo78xmYpUI3UWZ5R8%3D&reserved=0>
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure.io%2Ffedora-infrastructure&data=04%7C01%7Cgrant.byers%40aarnet.edu.au%7C8506a06c7aa848a455a808d9b0db31fd%7C4795f4d0a4b847c4af198dd47da5d8d4%7C0%7C0%7C637735277785366955%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=LaDwUPF7RLEfbsbKFDc9rxq771I2Yq8%2FyKDxPl6R77g%3D&reserved=0>



_______________________________________________
389-users mailing list -- 
[email protected]<mailto:[email protected]>
To unsubscribe send an email to 
[email protected]<mailto:[email protected]>
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/[email protected]
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

_______________________________________________
389-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to