On Mon, Nov 29, 2021 at 3:01 AM Grant Byers <Grant.Byers(a)aarnet.edu.au>
wrote:
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....
<
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
Hi Grant,
I agree. Feel free to open a bugzilla for the bug doc
and also a rfe about being able to handle certificate renewal when using
attribute encryption (there is clearly a hole in this area ...)
IMHO using a different key will just displace the problem. There still be
trouble when replacing that key (by nature the, probability a cryptographic
key get compromised increase over time, and it should be replaced after
some time (that is why certificates have expiration time))
)
IMHO we will probably need several keys (1 for encryption and a few others
to decrypt the attributes encrypted with older keys.
Anyway a sure thing is that this subject deserves thorough thinking.
Regards
Pierre
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 <Grant.Byers(a)aarnet.edu.au>
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 -- 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/
<
https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fe...
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
<
https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedorap...
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
<
https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.f...
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....
_______________________________________________
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/389-users@lists.fedoraproje...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
_______________________________________________
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/389-users@lists.fedoraproje...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
--
389 Directory Server Development Team