7:59 a.m.
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
--
2:20 a.m.
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(a)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(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...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
6:41 a.m.
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
6:42 a.m.
On 18 Jun 2019, at 13:41, Angel Bosch <abosch(a)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
6:46 a.m.
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.
7:12 a.m.
On 18 Jun 2019, at 13:46, Angel Bosch Mora
<abosch(a)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(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...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
6:50 a.m.
William Brown wrote:
> On 18 Jun 2019, at 13:41, Angel Bosch <abosch(a)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
1771
days inactive
1772
days old
389-users@lists.fedoraproject.org
6 comments
4 participants
participants (4)
-
Angel Bosch -
Angel Bosch Mora -
Rob Crittenden -
William Brown