hi,
I'm still evaluating some options to securize dynamic nodes and I have some questions regarding certutil and nss databases:
Can I create NSS databases on any directory/server and then move files to "/etc/dirsrv/slapd-instance_name" ?
If cert8.db and key3.db files are found in that directory are they used automatically by slapd process on reboot?
If both answers are affirmative I'll try to script it and hook it within my node creation flow. is there any other detail I should take care of with this approach?
thanks,
abosch
--
Hi there,
NSS databases are made from 3 files:
cert8.db key3.db secmod.db
If you are using the newer sqlite format, it's:
cert9.db key4.db pkcs11.txt
389 will "prefer" the newer format if present, and there is an automatic upgrade process in NSS. I'm not sure when NSS will swap by default, and I think if the upgrade is performed, then the "older" files will be ignored. This means if NSS upgrades these files, then replacement of key3.db etc will no longer be upgraded if key4 is present.
Regardless, provided you supply those 3 files to the directory, yes, it will work on the next reboot.
However, be mindful that the if you use attribute encryption, this value is stored in the key3.db, and replacement of this file WILL destroy your access to your own database! IE if you plan to use this strategy, you MUST NOT use attribute encryption at the same time.
A better process could be to have a systemd drop in file that on "start" takes .PEM files and turns them into the nss db, OR loads them into the existing NSS db. This would be useful upstream too, so maybe that's a better strategy, and of course, tools for PEM management are much better from a sys admin view. Would this be a cleaner approach do you think?
I hope this helps!
On 17 Jun 2019, at 14:59, Angel Bosch abosch@ticmallorca.net wrote:
hi,
I'm still evaluating some options to securize dynamic nodes and I have some questions regarding certutil and nss databases:
Can I create NSS databases on any directory/server and then move files to "/etc/dirsrv/slapd-instance_name" ?
If cert8.db and key3.db files are found in that directory are they used automatically by slapd process on reboot?
If both answers are affirmative I'll try to script it and hook it within my node creation flow. is there any other detail I should take care of with this approach?
thanks,
abosch
-- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
However, be mindful that the if you use attribute encryption, this value is stored in the key3.db, and replacement of this file WILL destroy your access to your own database! IE if you plan to use this strategy, you MUST NOT use attribute encryption at the same time.
I'll take that into account.
A better process could be to have a systemd drop in file that on "start" takes .PEM files and turns them into the nss db, OR loads them into the existing NSS db. This would be useful upstream too, so maybe that's a better strategy, and of course, tools for PEM management are much better from a sys admin view. Would this be a cleaner approach do you think?
do you have any docs about this process? I'm not really sure if I understand you when you say "This would be useful upstream too", can you elaborate?
abosch
On 18 Jun 2019, at 13:41, Angel Bosch abosch@ticmallorca.net wrote:
However, be mindful that the if you use attribute encryption, this value is stored in the key3.db, and replacement of this file WILL destroy your access to your own database! IE if you plan to use this strategy, you MUST NOT use attribute encryption at the same time.
I'll take that into account.
A better process could be to have a systemd drop in file that on "start" takes .PEM files and turns them into the nss db, OR loads them into the existing NSS db. This would be useful upstream too, so maybe that's a better strategy, and of course, tools for PEM management are much better from a sys admin view. Would this be a cleaner approach do you think?
do you have any docs about this process? I'm not really sure if I understand you when you say "This would be useful upstream too", can you elaborate?
The feature doesn't exist yet, so if you write a PEM -> NSS tool, the project would love to accept it to our source code. It's been something I have wanted for a while, and recently I have been thinking with containers I should more seriously develop it, but if you wanted to add this, we would review and help you achieve it :)
abosch
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
The feature doesn't exist yet, so if you write a PEM -> NSS tool, the project would love to accept it to our source code. It's been something I have wanted for a while, and recently I have been thinking with containers I should more seriously develop it, but if you wanted to add this, we would review and help you achieve it :)
ok, I can try to do my best. The think is I mostly use bash for my scripts with a little python here and there, but I can try to write a helper and see if it works.
abosch -- Institut Mallorqui d'Afers Socials. Aquest missatge, i si escau, qualsevol fitxer annex, es dirigeix exclusivament a la persona que n'es destinataria i pot contenir informacio confidencial. En cap cas no heu de copiar aquest missatge ni lliurar-lo a terceres persones sense permis expres de l'IMAS. Si no sou la persona destinataria que s'hi indica (o la responsable de lliurar-l'hi) us demanam que ho notifiqueu immediatament a l'adreca electronica de la persona remitent. -- Abans d'imprimir aquest missatge, pensau si es realment necessari.
On 18 Jun 2019, at 13:46, Angel Bosch Mora abosch@imasmallorca.net wrote:
The feature doesn't exist yet, so if you write a PEM -> NSS tool, the project would love to accept it to our source code. It's been something I have wanted for a while, and recently I have been thinking with containers I should more seriously develop it, but if you wanted to add this, we would review and help you achieve it :)
ok, I can try to do my best. The think is I mostly use bash for my scripts with a little python here and there, but I can try to write a helper and see if it works.
Great! There are things in lib389 we can use too, and I'm always happy to review, advise, and write code if you need. Thanks!
abosch -- Institut Mallorqui d'Afers Socials. Aquest missatge, i si escau, qualsevol fitxer annex, es dirigeix exclusivament a la persona que n'es destinataria i pot contenir informacio confidencial. En cap cas no heu de copiar aquest missatge ni lliurar-lo a terceres persones sense permis expres de l'IMAS. Si no sou la persona destinataria que s'hi indica (o la responsable de lliurar-l'hi) us demanam que ho notifiqueu immediatament a l'adreca electronica de la persona remitent. -- Abans d'imprimir aquest missatge, pensau si es realment necessari. _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
William Brown wrote:
On 18 Jun 2019, at 13:41, Angel Bosch abosch@ticmallorca.net wrote:
However, be mindful that the if you use attribute encryption, this value is stored in the key3.db, and replacement of this file WILL destroy your access to your own database! IE if you plan to use this strategy, you MUST NOT use attribute encryption at the same time.
I'll take that into account.
A better process could be to have a systemd drop in file that on "start" takes .PEM files and turns them into the nss db, OR loads them into the existing NSS db. This would be useful upstream too, so maybe that's a better strategy, and of course, tools for PEM management are much better from a sys admin view. Would this be a cleaner approach do you think?
do you have any docs about this process? I'm not really sure if I understand you when you say "This would be useful upstream too", can you elaborate?
The feature doesn't exist yet, so if you write a PEM -> NSS tool, the project would love to accept it to our source code. It's been something I have wanted for a while, and recently I have been thinking with containers I should more seriously develop it, but if you wanted to add this, we would review and help you achieve it :)
I don't believe this is supported anymore but there is a PKCS#11 PEM reader plugin for NSS, https://github.com/kdudka/nss-pem
Or a version written using OpenSSL is soft-pkcs11 but the original location is gone. There may be a tar file lying around somewhere though.
rob
389-users@lists.fedoraproject.org
-
Angel Bosch -
Angel Bosch Mora -
Rob Crittenden -
William Brown