openssl usecase?

[cagney]

Lets assume I have a private key in an openssl. How can I use this tool to make that same key available from NSS?

[cagney]

     * The initialization string format is a space-delimited file of
     * pairs of paths which are delimited by a semi-colon. The first
     * entry of the pair is the path to the certificate file. The
     * second is the path to the key file.
     *
     * CA certificates do not need the semi-colon.
     *
     * Example:
     *  /etc/certs/server.pem;/etc/certs/server.key /etc/certs/ca.pem

that's a start

[cagney]

looking hopeful:

# modutil -create -dbdir /tmp
# modutil -dbdir /tmp -add nss-pem -libfile /usr/lib64/libnsspem.so -string '/testing/x509/certs/east.crt'
# modutil -dbdir /tmp -rawlist
library="/usr/lib64/libnsspem.so" name="nss-pem" parameters="/testing/x509/certs/east.crt"

[kdudka]

You only need nss-pem if you want to use PEM files directly at run-time. If importing the keys and certificates into NSS database is an option for you, then you do not need nss-pem at all.

nss-pem was primarily used by libcurl but the code in libcurl that uses nss-pem is about to be decommissioned soon: https://curl.se/mail/lib-2022-01/0120.html

[cagney]

To the best of my knowledge, the only way to make a raw key in OpenSSL available via the NSS library is to export it as PEM and then use nss-pem? See https://github.com/libreswan/libreswan/issues/98

(if you're wondering why I used a cert when playing around it is because that is all I had immediately to hand within a test framework)

[kdudka]

I do not know libreswan but NSS itself reads certificates and keys from its database stored on the file system. See: https://bugzilla.redhat.com/show_bug.cgi?id=266021#c3

[cagney]

I do not know libreswan but NSS itself reads certificates and keys from its database stored on the file system. See: https://bugzilla.redhat.com/show_bug.cgi?id=266021#c3

And Libreswan is no different.

Can we perhaps focus on the question? How can a .pem file be accessed using nss-pem and NSS?

There's zero documentation.

[kdudka]

And Libreswan is no different.

Then you should be able to put the key into NSS database to avoid the need to use nss-pem.

How can a .pem file be accessed using nss-pem and NSS?

libcurl uses PK11_CreateManagedGenericObject() from public NSS API to make it load certificates and keys through nss-pem, which itself is loaded by SECMOD_LoadUserModule():

https://github.com/curl/curl/blob/b7c0bd68ffc0778ce0440439ac317da5a0765931/lib/vtls/nss.c#L471 https://github.com/curl/curl/blob/b7c0bd68ffc0778ce0440439ac317da5a0765931/lib/vtls/nss.c#L1315

There is some code in nss-pem to parse out paths to PEM files directly from the module initialization string but libcurl has never used it and the code has never had any test coverage, so it is likely full of nasty bugs:

https://github.com/kdudka/nss-pem/blob/0c7d4e2d9b0ba8d596aa887b9f8da02be6a271d7/src/pinst.c#L677

There's zero documentation.

That is true, unfortunately. And it is yet another reason for not using nss-pem for your task.

[cagney]

And Libreswan is no different.

Then you should be able to put the key into NSS database to avoid the need to use nss-pem.

Er, this is about raw keys.

[cagney]

There is some code in nss-pem

Which I quoted in my second comment!!

[cagney]

It doesn't handle only being given the private key., as in: -string ';/etc/ipsec.d/east.pem'

[kdudka]

Which I quoted in my second comment!!

Indeed. So that is the exactly the code that I think is broken. It is also possible that the comment does not match the actual implementation. But I am not against fixing it (and/or extending for your use case) if you have a reliable way to test it.

[cagney]

There's no testsuite.

[cagney]

Here are some notes from playing with the code:

• things are RSA only (not surprising giving the code's era)
• things like <<certutil -K -d ...>> don't seem to work (but this is probably user error)
• NSS really also wants the public key; which means having to provide that anyway

[paulwouters]

It would indeed be nice if we could import raw keys but I think one issue is that NSS expects some kind of import encryption. If nss-epm offers this by doing a pkcs#12 on the private key, that would be great to use.

[cagney]

There's a workaround.

Use the raw PEM encoded private key to generate a self-signed cert and then bundle the pair up as PKCS#12. pk12util can then be used to import it.