Open Bug 1439939 Opened 6 years ago Updated 2 years ago

Exported p12 client certificate fails to load in Powershell and IE

Categories

(NSS :: Libraries, defect, P5)

Unspecified
Windows

Tracking

(firefox60 affected)

UNCONFIRMED
Tracking Status
firefox60 --- affected

People

(Reporter: zao, Unassigned)

Details

I've got a grid client certificate which when exported from Firefox as a .p12 can't import in neither Internet Options on my Windows 10 machine, nor be parsed by PowerShell's Get-PfxData.

The error from IE is a generic "wrong password" while PowerShell's Get-PfxData reports:

Get-PfxData : An error occurred during encode or decode operation. 0x80092002 (-2146885630 CRYPT_E_BAD_ENCODE)

This holds for certs exported by both Linux and Windows Firefox Nightly.

The very same certificate imports fine in Linux Chrome and once re-exported from Chrome, imports fine on Windows.

I've also got an older (expired) certificate from the same issuer that I can export and import correctly with the same Firefox version.

Both certs should be SHA2 ones issued by Terena via Digicert, the only real difference I see in them according to openssl's command line tool is that the friendlyName of the bogus one has:

friendlyName: First Last id@site.tld^Ys TERENA ID

while the good one is:

friendlyName: First Last id@site.tld's TERENA ID

The ^Y above is a literal 0x12 in the output from openssl.

I've got more of the new and old certificates, and the cutoff point from working to broken seems to be when the friendlyName changes.

Are we somehow violating some encoding rules about nonprintable characters that Windows trips on?
I'm sorry, I mixed the files up a bit and botched the hex for ^Y.
Even the older certificate breaks once exported from Firefox.

The difference in friendlyName is between the original certificate I imported into Firefox (which has the apostrophe), and the one exported from Firefox (which has the 0x19 ^Y).
Assignee: nobody → nobody
Component: Untriaged → Libraries
Product: Firefox → NSS
Version: Trunk → other
I have the same problem.
Since firefox 58 cert export function generates wrong *.p12 file which Cannot be imported in Internet Explorer on Windows.
Import proccess (in IE) prompts 'Invalid password' message.
I'll corroborate this issue: Firefox 59 exported P12 files cannot be imported into Windows 10 machines (10.0.16299.2448) using Certificate Manager. Error reported is "incorrect password". Certificate can be imported into Firefox without an issue.

Certificate can also be imported successfully by Kleopatra on Linux.

Appears to also be corroborated by https://superuser.com/questions/1295305/certificate-export-from-firefox-import-to-windows-store
OS: Windows 10 - Version 10.0.16299 build 16299

Firefox Quantum 59.0.2 (64-bit)

Following Certificates effected. 
Code Signing Certificates.
Admin ID Certificates / Device Tokens. 

Issue: 
All Certificates exported as p12 from Firefox experience "The Password you entered is Incorrect."

Impact:
This has a huge impact with Certificate Authorities as many only use Firefox for keypair certificate creation as Microsoft Edge & Google Chrome lacks the ability to generate fully functional certificate keypairs.

Current work around I found for Code Signing certificates Is to use the Digicert Certificate Utility for Windows. (using all the same password and Firefox p12 code signing cert that was generated) import the failed password p12 file into the utility then re-export the certificate from the utility. Windows systems then accept the p12 file after password entry.
Priority: -- → P5
I have also run into this issue and have a workaround that utilises OpenSSL;

1. Export you current certificate to a passwordless pem type:
openssl pkcs12 -in mycert.pfx -out tmpmycert.pem -nodes
Enter Import Password:
MAC verified OK

2. Convert the pem file to a new pfx file with password:
openssl pkcs12 -export -out mycert2.pfx -in tmpmycert.pem
Enter Export Password:
Verifying - Enter Export Password:

This will now be importable either via the MMC, IE or the Installation Wizard
Same issue here. 59.0.2 (64-bit) on Windows.

As an extra information, in my cert there's also a "'" character in the "friendly name", it ressembled this structure: "LAST1 LAST2 NAME - 00000000F's FNMT-RCM ID".

I **confirm** the openssl trick **worked** fine.
Same issue as Xavi, same version and platform, with a similar Spanish FNMT certificate. In my case the ASCII code of the "'" character in the pem generated by open ssl from the p12 file exported by firefox is 25 (decimal).
The openssl trick also worked for me.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.