Project

General

Profile

Actions

Bug #3154

closed

pfSense should not require users' private keys to be uploaded to generate certificates.

Added by N. CANIART about 12 years ago. Updated about 12 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
08/21/2013
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Affected Version:
Affected Plus Version:
Affected Architecture:

Description

Hi,

In the certificate manager, the UI used to import existing certificates requires that you provide both the certificate and the private key. The only reason for that is I guess to allow the generation of the .zip or .exe to easy OpenVPN setup on client machines.

I would rather assume that, if one has chosen to import certificates, it has other facilities to do this, or has chosen not to use this kind of tools. Could (or should) not this field be made optional ? And then, I guess, the easy set-up tools should be disabled if no private key is available for a user.

By the way, this feels very insecure to me as a breach in pfSense may allow an attacker to impersonate any user who's certificate are found there. Indeed, both pieces of any users credentials can be retrieved from the pfSense machine. And since pfSense is a firewall/router distribution, it is likely to be the first machine an attacker may hit on a network.

In a general manner, would not it be more sane to advise users not to upload private keys on the pfSense box. Compromising security in favor of "ease of use" that way feels really strange.

Regards,
Nicolas.

Actions #1

Updated by Jim Pingle about 12 years ago

  • Status changed from New to Rejected

This is better handled as a discussion on the forum rather than here in the bug tracker.

Currently there are no functions in the GUI that would require a certificate to be present in the GUI that do not also require the private key. You can import a CA without the private key but you can't generate new certificates from it in the GUI, or make a new CRL. They key is required for those. For certificates, every function in the GUI currently that could use a cert needs the key.

Eventually some may exist that do not, and then the GUI can be adjusted so it's not required, but that will also require code everywhere else that does need it so that such certificates can be rejected.

For things like OpenVPN clients you do not need to have the certificates imported into the GUI for the clients to work. They only need to be in the GUI for client export, which would need the key to make a proper working client.

If you have an external CA setup, you can simply import the CA cert (no key) and whatever cert+keys you do need (e.g. OpenVPN server) but the other user certs do not need to be in the GUI for it to function, since certificates aren't verified by their presence in the GUI, only that they were made from the correct CA and are otherwise valid.

It is a potential security issue, but it can be mitigated by using an external CA structure management system/process. In an ideal world, that would be on a separate system not connected to any network, but that is also much less convenient.

Actions

Also available in: Atom PDF