#50007 Support PEM files
Closed: fixed 5 days ago by firstyear. Opened a year ago by firstyear.

Issue Description

We should support reading certificates from PEM files. This process would likely just "import on startup" to the NSS db. PEM is much simple to work with, is the current industry standard, and would allow us to operate with tools like lets encrypt. It would make admins lives much much easier.

We could make the NSS DB a private implementation detail of the server.


Metadata Update from @mreynolds:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None
- Issue set to the milestone: 1.4.1

10 months ago

Metadata Update from @firstyear:
- Issue assigned to firstyear

3 months ago

I'm going to work on this soon. I think the path of least resistance is a pre-start python script part of lib389 that converts pem -> nss db while preserving the nssdb instance due to possible secmod.db key presence.

For containers this would be part of ds-container to do the conversion.

Does that seem reasonable @mhonek ?

@firstyear, @mhonek, sorry in advance for the dummy question but I would like to clarify a security concern.
NSS db contains sensitive data and is protected by a password that can be stored in a file. A security concern is that the file permission protection of the password file looks weak ( so moving to nuxwdog for the password).
Pem files also contains sensitive data. Is the file permission the only protection of those data ?

Yes. However, the entire discussion needs to consider a key point of the threat model. On most installs pin.txt exists in the same folder as the nssdb, so all nssdb encryption and security hinges on file permissions of pin.txt. This is before we discuss the un-ending list of security weaknesses and misconfigurations that exist in any linux install.

As a result there is zero measurable improvement between pem vs nssdb in a default setup of directory server.

Even if we consider a deployment that has nssdb with no pin.txt (and we use systemd-ask-pass, which is exceedingly rare), we need to consider the extensive numebr of historical security issues in linux, which a median resolution time of 7 years the last time I saw stats (from introduction of the vuln, I think it was about 5 years to "good people" detecting, and another 2 years to resolution). So we have to always assume that anyone who can run any code as any user on a piece of hardware is effectively the same as root (this has been fundamentally blown out of the water by things like spectre and such). Which is why most serious ldap deployments run on dedicated hardware and only run directory server on that machine to isolate it providing a proper hardware isolation and barrier.

As a result, this does not weaken - or improve - security of the system. But it does make it much easier to use!

Metadata Update from @firstyear:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

5 days ago

Login to comment on this ticket.

Metadata