When using Import-PFXCertificate to import PFXs that contain a private key the private key appears to be stored using CNG "Microsoft Software Key Storage Provider" instead of the legacy format "Microsoft Enhanced Cryptographic Provider v1.0"

Most Microsoft products can't read this format.

The PS-Drive Provider "Certificate" can't even read keys in this format.

It would be helpful to update the CMDLet to support CNG, however, as pointed out in this article: https://www.sysadmins.lv/blog-en/retrieve-cng-key-container-name-and-unique-name.aspx - almost no .NET apps use CNG because it has only been accessible via native APIs.

Without being able to force the key storage format to the older format this CMDLet only adds confusion for many deployments rather than adding needed functionality as the results of it's work are unusable by most of the existing software.

This was reported here: https://social.technet.microsoft.com/Forums/office/en-US/ea287f42-8a17-4c76-be41-61d66f645a63/bug-in-ps-importpfxcertificate-verify?forum=winserverpowershell

And there is a deep dive on the problem here: https://www.sysadmins.lv/blog-en/retrieve-cng-key-container-name-and-unique-name.aspx

When using the interactive Windows Certificates snap-in, a 3rd very important cert target store type can be selected:
One can select "my user account", "computer account" and "service account" as target for certificates.

xCertificateImport currently seems to only support 2 target store types:
Location: 'LocalMachine' or 'CurrentUser'

As an admin it would be very cool to be able to also use xCertificateImport to also manage service-related certificates, as there are otherwise no PowerShell means to do so and the GUI cert tool is a PITA, as its not scriptable. And there are Microsoft own services out there that needs such certificates. For example Microsoft AD LDS uses certificates stored in the service accounts section for SSL/TLS certificates. e.g. in:
[HKLM\SOFTWARE\Microsoft\Cryptography\Services\ADAMinst1\SystemCertificates\My\Certificates]
There seems to be no means to use xCertificateImport to manage that path
(Referring to https://msdn.microsoft.com/en-us/library/windows/desktop/aa388136(v=vs.85).aspx#CERTSYSTEMSTORESERVICES)

(the old fashioned state based Powershell Cert commands seem to have the same deficits, but why not do it right in this command - that would probably need a 3rd parameter Location="service" and a further Servicename="...." parameter)

The whole CA management interface feels so overdue. i know the whole certificate thing wasnt built by microsoft and it pushed into the marked real fast (relatively speaking) so a solution had to be realized quick. The whole topic is very clumsy and involves so many manual steps that it gives lots of admins around the globe headaches. It is also very hard to learn and master due to the wrong tools i think.

The certification management in exchange control panel 2013 seems a step in the right direction. I cant really tell you what to do, but im sure that if the right guys at microsoft sit together, think and talk about this, something great comes out of it.

Dont get me wrong, this really isnt a Microsoft problem here. its a industry wide problem. But Microsoft could bring out a completely revised certification management (client and server) with their next version of windows and roll the dice to change the whole industry here. Just as other competitors have done with multitouch for example.