search

dogtagpki / jss

Network Security Services for Java is a Java interface to NSS
https://dogtagpki.github.io/jss
19 stars 30 forks source link

Add support for loading keys from .p12 #680

Open Januson opened 3 years ago

Januson commented 3 years ago

The title says it all. It would help us if JSS could support loading keys from a .p12 blob.

cipherboy commented 3 years ago

Just to add a bit more to this ticket:

From a Candlepin perspective, they'd like to specify .p12 files in the Tomcat server.xml file and have Tomcat automatically load the keys. They'll probably use a security.properties override and initialize JSS with a standard NSS DB (/etc/pki/nssdb probably) and then use the .p12 file to actually load the server certificate (instead of putting them in the NSS DB). This gives them a minimum upgrade path from using BouncyCastle to JSS.

AFAIK, this mostly means that we have to extend JSS to expose a PKCS12-typed keystore, similar to the standard JDK providers (or BouncyCastle). All of the pieces should be here, this is mostly JCA parity work and making sure that it can be used by SunJSSE. If we do this correctly, the private keys should be unwrapped during parsing the .p12 bundle (and not read in plaintext), thus letting us import them even in FIPS mode (a requirement for this ticket).

edewata commented 3 years ago

Is importing the PKCS #12 file into an NSS database before starting Tomcat out of the option?

Just FYI, we have this doc for setting up SSL in Tomcat with PKCS #12 file and PKCS #11 using NSS: https://github.com/dogtagpki/pki/blob/master/docs/installation/server/Installing_Basic_PKI_Server.md I was wondering if you have tried combining the two methods, i.e. using PKCS #12 file with a --keystoreProvider Mozilla-JSS.

cipherboy commented 3 years ago

@edewata The issue is that Satellite/Candlepin previously used BouncyCastle with a .p12 blob for their keys, so as they switch to JSS, they'd need to also migrate their Tomcat configuration. If they could instead use the default system-wide NSS DB (/etc/pki/nssdb like they currently do), I don't think you'd have to change any Tomcat configuration if JSS provides a .p12 loader to the in-memory database and they changed their .service file to use the java.security file to load the JSS provider in the first slot. Just a thought :-)

edewata commented 3 years ago

I think most of the PKI commands there were just provided for convenience. For example, the pki-server http-connector-add adds <Connector> and <SSLHostConfig> elements: https://github.com/dogtagpki/pki/blob/master/base/server/python/pki/server/cli/http.py#L218-L231 The pki-server http-connector-cert-add adds a <Certificate> element: https://github.com/dogtagpki/pki/blob/master/base/server/python/pki/server/cli/http.py#L1056-L1064 The pki-server jss-enable adds a JSSListener from TomcatJSS into server.xml, which can be configured to use the system-wide NSS database (or maybe it should by default): https://github.com/dogtagpki/pki/blob/master/base/server/python/pki/server/cli/jss.py#L95-L104

So if you already have a Tomcat instance and have JSS and TomcatJSS installed, the above configuration can be done manually, and I don't think PKI is needed for this. What I'm not sure is whether the combination of PKCS #12 and Mozilla-JSS provider will work. If it doesn't then it's something that might need to be fixed in JSS.

edewata commented 3 years ago

As discussed on IRC, I'd suggest to create a custom server.xml with PKCS #12 and Mozilla-JSS provider so we can focus on this particular issue.

Once we have that working, we can try using the security.properties, and if we find other issues we can address that in a separate ticket.