Project

General

Profile

Actions

Bug #13257

closed

Exporting a PKCS#12 file from the certificate manager does not use the intended encryption algorithm

Added by Jim Pingle 6 months ago. Updated about 2 months ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Certificates
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
23.01
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

In source:src/usr/local/www/system_certmanager.php#L198 or thereabouts it sets a parameter encrypt_key_cipher intending to use AES-256 for exporting a PKCS#12 file. The parameter used is not honored by PHP. It isn't listed in the documentation for openssl_pkcs12_export(), nor in the source, and the resulting PKCS#12 file is created using the OpenSSL default RC2+3DES algorithms.

OpenSSL is deprecating RC2 in OpenSSL 3.0, so we should fix this for the next release if possible, in one of two ways:

1. Wait until we import PHP 8.1 and see if this is fixed there. Based on the source, I doubt it is, but worth checking.
2. Change from the PHP function to make a PKCS#12 cert to using OpenSSL directly as is done on the OpenVPN client export package. When exporting there, we can pass -certpbe AES-256-CBC -keypbe AES-256-CBC which results in a file encrypted with the expected algorithms.


Related issues

Has duplicate Bug #13472: Cert Manager and OpenVPN exporter use **obsolete** sig/algo combinationDuplicate

Actions
Actions #1

Updated by Jim Pingle 6 months ago

See also: #13255

Actions #2

Updated by Jim Pingle 5 months ago

  • Plus Target Version changed from 22.09 to 22.11
Actions #3

Updated by Jim Pingle 3 months ago

This is not fixed on PHP 8.1, so option 2 seems to be the path forward here.

Actions #4

Updated by Jim Pingle 3 months ago

  • Has duplicate Bug #13472: Cert Manager and OpenVPN exporter use **obsolete** sig/algo combination added
Actions #5

Updated by Jim Pingle 3 months ago

  • Status changed from New to In Progress
Actions #6

Updated by Jim Pingle 3 months ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100
  • Private changed from Yes to No

I merged changes which move from using the native PHP function to using OpenSSL directly so we can control the algorithms involved.

Exported archives now use AES-256 and SHA256:

$ openssl pkcs12 -info -in jimp.p12 -passin pass:abc123 -passout pass:abc123 
MAC: sha256, Iteration 2048
MAC length: 32, salt length: 8
PKCS7 Encrypted data: PBES2, PBKDF2, AES-256-CBC, Iteration 2048, PRF hmacWithSHA256
[...]
PKCS7 Data
Shrouded Keybag: PBES2, PBKDF2, AES-256-CBC, Iteration 2048, PRF hmacWithSHA256

We could also consider increasing the iterations if need be.

Actions #7

Updated by Jim Pingle 3 months ago

The new export code works fine on internal snapshots, though we should probably test how well other systems can read/import the .p12 files.

Also the OpenVPN client export package should probably be updated to tie into this new function so it isn't duplicating effort, but that will be a separate Redmine task. Even if it doesn't use this function it should be changed to use the same algorithms since it already calls OpenSSL to make the archive in a similar way.

Actions #8

Updated by Jim Pingle 3 months ago

  • Status changed from Feedback to In Progress

The new files import OK into pfSense (current snapshots, 22.05, and 2.6.0) and a current Windows 10 at least, but apparently macOS is not yet compatible with the higher encryption, nor are older versions of Windows. macOS fails to import the P12 into its cert manager, though it can read them at the CLI with the openssl command.

The older versions of Windows aren't a significant concern, but macOS is, so it looks like we might need an option to weaken the security down to 3DES/SHA1 while defaulting to stronger encryption. It's OK to only make this available from the cert edit screen for now as both macOS and Windows need the export password defined anyhow.

Actions #9

Updated by Jim Pingle 3 months ago

  • Status changed from In Progress to Feedback

Added an option to change the encryption level to high (AES-256+SHA256), low (3DES+SHA1), and legacy (RC2-40 + SHA1). Most things non-macOS are good with "high", and macOS is happy with "low". Anything even older can use "legacy".

Actions #10

Updated by Chris Linstruth about 2 months ago

I looked at this mainly using macos as a client and it seemed to function well. Successful import using "low" and unsuccessful using "high".

Actions #11

Updated by Jim Pingle about 2 months ago

  • Status changed from Feedback to Resolved

That's a good enough test in addition to all the testing I've done. It's passed and functional testing and inspection of the results I've done thus far.

I'll close this out, we can always revisit if someone has an issue.

Actions #12

Updated by Jim Pingle about 2 months ago

  • Plus Target Version changed from 22.11 to 23.01
Actions

Also available in: Atom PDF