precreation nss databases

[Angel Bosch]

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




--

[William Brown]

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&gt;
> 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/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Angel Bosch]

>  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

[William Brown]

>  On 18 Jun 2019, at 13:41, Angel Bosch <abosch(a)ticmallorca.net&gt;
> 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

[Angel Bosch Mora]

>  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.

[Rob Crittenden]

William Brown wrote:
>  
>  
> > On 18 Jun 2019, at 13:41, Angel Bosch <abosch(a)ticmallorca.net&gt; 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

[William Brown]

>  On 18 Jun 2019, at 13:46, Angel Bosch Mora
> <abosch(a)imasmallorca.net&gt; 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/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs