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@xxxxxxxxxxxxxxx> 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@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 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 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
