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