PfxImport fails for files encrypted with AES256-SHA256

[NReilingh]

Details of the scenario you tried and the problem that is occurring:
When using the certificate export wizard, you are given the option to use TripleDES-SHA1 encryption or AES256-SHA256 encryption to protect the certificate using a password and/or AD DS groups and users. Set-TargetResource for PfxImport of an AES256-encrypted file fails with "The PFX file you are trying to import requires either a different password or membership in an Active Directory principal to which it is protected."

I had to solve a bunch of issues related to user groups and share access before getting to this point, so I'm confident I've localized the problem. Initially, my PFX file was password protected, then I switched to AD DS principal security, and then finally I switched to using TripleDES-SHA1 encryption (with AD DS security) and I stopped receiving the above error.

The DSC configuration that is using the resource (as detailed as possible):

        PfxImport $cert.Thumbprint
        {
            Ensure = "Present"
            DependsOn = "[WindowsFeature]Web-Server"
            Thumbprint = $cert.Thumbprint
            Path = $cert.Path
            Location = "LocalMachine"
            Store = "WebHosting"
        }

Version of the Operating System and PowerShell the DSC Target Node is running:
Target node is Server 2016, certificate path is on a DFS share on another Server 2016 machine, and I am using a DSC Push configuration from a Windows 10 Pro machine (which was also doing the cert exporting and encryption).

Version of the DSC module you're using, or 'dev' if you're using current dev branch:
CertificateDsc 4.1.0.0

[johlju]

Just so I'm following you, you solved it by changing to the TripleDES-SHA1 encryption, and "solve a bunch of issues related to user groups and share access". But if you just switched to the encryption AES256-SHA256 the resource fails?

Did you have to code changes to get the TripleDES-SHA1 encryption scenario working? If so you are more than welcome to send in a PR for those changes.

Also a documentation PR (or just submitting to this issue) on what you needed to do to "solve a bunch of issues related to user groups and share access" would also be greatly appreciated, for other users with the same problem. 🙂

/cc @PlagueHO

[NReilingh]

@johlju Sorry, I guess I unnecessarily confused the issue. The user group and share issues I mentioned are irrelevant, and not related to the CertificateDsc resource (and at the end of the day they were more user misunderstandings than functionality issues).

So to clarify, importing a TripleDES-SHA1 -encrypted certificate works as expected with no code changes or workarounds. The issue I am reporting is that attempting to import an AES256-SHA256 -encrypted cert with PfxImport fails with an inaccurate error message.

[johlju]

Thank you for reporting the error btw!

To clarify more. 🙂 When you say "inaccurate error message". Does that mean that you would expected it to throw an error, just not that error message text? Or are you expecting it to not throw an error and import the certificate?

[NReilingh]

From the perspective of a user who doesn’t know any better, the “expected behavior” would be for the import to succeed and not throw an error. :-)

But if there are implementation details or other limitations preventing this, then an error about the encryption mechanism being not supported would be acceptable.

If we can’t tell what encryption mechanism is used until we’ve got a successful import, then the existing error message just needs to be changed to include the additional possibility of unsupported encryption mechanisms.

It appears that the ability to export using AES256 was a relatively recent addition to Windows 10, so it makes sense that the notion of multiple possible encryption mechanisms hasn’t been accounted for everywhere.

[PlagueHO]

Sorry for taking so long to look into this, but I'll check this out today. This may be a limitation with the underlying Import-PfxCertificate cmdlet that comes with Windows. We use this cmdlet to perform the import in the DSC Resource.

@NReilingh - have you exported the certificate using Export-PfxCertificate -CryptoAlgorithmOption AES256_SHA256 as well, or just used the Wizard?

I should be able to identify if the problem is within the underlying *-PfxCertificate cmdlets fairly easily. If this is a problem with them, then I'll raise a uservoice issue with the appropriate Windows team. We will be able to document the issue and possibly put a warning in the logs, but it really depends on the behavior of the Import-PfxCertificate cmdlet.

If it is not a problem with the cmdlet then we may be able to fix it.

[PlagueHO]

Hi @NReilingh - as I suspected, there are different versions of the Import-PfxCertificate and Export-PfxCertificate. The versions that come with Windows Server 2016 and Windows 10 1703 and earlier do not support importing a PFX generated using AES256_SHA256 and result in the following error:

Newer versions of the cmdlets, like the ones that come in Windows Server 2016 1709 and Windows 10 1709 and newer, do support this. So this resource does work with AES256_SHA256 but only when being applied to nodes with the newer cmdlets.

I actually created some new integration tests to validate this: https://github.com/PlagueHO/CertificateDsc/blob/Issue-153/Tests/Integration/MSFT_PfxImport.Integration.Tests.ps1#L48

These tests fail in AppVeyor because the cmdlets on there are the older ones: https://ci.appveyor.com/project/PlagueHO/certificatedsc#L624 and don't allow exporting PFX files when specifying the algorithm.

They work on my Windows 10 1709 just fine.

Technically we could attempt to catch the exception returned when trying to import AES256_SHA256 PFX certificates using older cmdlets and put a warning suggesting this to be a problem, but I'd much rather just document the limitation in the README.MD for the resource as we've done in other resources. The reasons for this are:

1. We are relying on a "bad behavior" of the underlying cmdlets
2. Less code (means less to test as well)
3. Catching an error in a try...catch that could be caused by a number of different things just to log an entry about one possible cause is not a good reason to obfuscate the underlying error.

@johlju - does the README.MD option seem like the best approach?

[johlju]

@PlagueHO I agree that it would be sufficient to just document this in the README.md. A ## Requirements section maybe? The requirement is to use build 1703 or newer for AES256_SHA256.
Example here https://github.com/PowerShell/SqlServerDsc#requirements-13