none
Bug in PS Import-PfxCertificate - Verify? RRS feed

  • Question

  • I have run into an insidious bug with the Import-PfxCertificate on Windows 2012 R2. When attempting to use this cmdlet, the certificate and cert authority that signed it are successfully imported, but the private key is not. What makes this totally crazy is that the command succeeds, and even the HasPrivateKey bit is set, but the PrivateKey value is null. A long time ago when I ran into this problem I switched to running certutil to do the import instead, and that worked all the way up till now, and evidently the timing/downstream mechanism that is calling certutil (we do this in AWS EC2 during instance bootstrap) has changed in a way that makes this command also succeed but generate bogus private key data. Here is an example of the boom:

    Import-PfxCertificate -CertStoreLocation cert:\LocalMachine\My -Password $pw -FilePath C:\PropertyFiles\my_cert.pfx

    This cmdlet generates no errors and does product a certificate entry. When I look at the cert details I get the following:

    PSPath                   : Microsoft.PowerShell.Security\Certificate::LocalMachine\My\A2455AA3A4D4E553B3FF4023DEE2B49F9
                               9638827
    PSParentPath             : Microsoft.PowerShell.Security\Certificate::LocalMachine\My
    PSChildName              : A2455AA3A4D4E553B3FF4023DEE2B49F99638827
    PSDrive                  : Cert
    PSProvider               : Microsoft.PowerShell.Security\Certificate
    PSIsContainer            : False
    EnhancedKeyUsageList     : {}
    DnsNameList              : {IR_SDK_CERT}
    SendAsTrustedIssuer      : False
    EnrollmentPolicyEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty
    EnrollmentServerEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty
    PolicyId                 :
    Archived                 : False
    Extensions               : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid}
    FriendlyName             : ir_sdk_cert
    IssuerName               : System.Security.Cryptography.X509Certificates.X500DistinguishedName
    NotAfter                 : 12/9/2021 6:23:17 PM
    NotBefore                : 12/9/2016 6:23:17 PM
    HasPrivateKey            : True
    PrivateKey               :
    PublicKey                : System.Security.Cryptography.X509Certificates.PublicKey
    RawData                  : {48, 130, 3, 173...}
    SerialNumber             : 008D8EA7B711E7ED508CA6550E0E1EF0E8
    SubjectName              : System.Security.Cryptography.X509Certificates.X500DistinguishedName
    SignatureAlgorithm       : System.Security.Cryptography.Oid
    Thumbprint               : A2455AA3A4D4E553B3FF4023DEE2B49F99638827
    Version                  : 3
    Handle                   : 1008768248560
    Issuer                   : C=US, S=NY, L=New York, O=Infor, OU=Infor Labs, CN=IR_CA_ir-certgen-lambda-ca2
    Subject                  : C=US, S=NY, L=New York, O=Infor, OU=Infor Labs, CN=IR_SDK_CERT

    Note that the HasPrivateKey attribute is set to True, but PrivateKey is null. On a valid import, PrivateKey should be  System.Security.Cryptography.RSACryptoServiceProvider. If I run certutil -importpfx -p password C:\PropertyFiles\my_cert.pfx AFTER the system has bootstrapped, this value has been filled in, and the cert is usable by a .NET app that's trying to utilize it. However, in _all_ cases in PS and in the bootstrap case with certutil, this is blank.

    Can I get a verification that this is a bug, and any potential other alternate workarounds, I would very much appreciate it.

    Thanks!

    Donavan


    Thursday, December 22, 2016 7:21 PM

All replies

  • Hi,

    >>Can I get a verification that this is a bug, and any potential other alternate workarounds, I would very much appreciate it.

    Same result in my testing environment:

    Besides, you could check the private key in mmc->cert, see figure above.

    In addition, please post feedback on link below to get more help:

    https://windowsserver.uservoice.com/forums/301869-powershell

    Best regards,

    Andy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, December 23, 2016 3:57 AM
    Moderator
  • One of the issues I see with this "bug" is that it is not possible to execute the scripts that we can found to allow permissions to some users like NETWORK SERVICE.

    Those shell scripts rely in this private key container name (privatekey.cspkeycontainerinfo.uniquekeycontainername) to set ACL under c:\programdata\microsoft\crypto\rsa\machinekeys key files.

    Is there any workaround for this?

    Friday, March 2, 2018 8:41 AM
  • I have the same issue. If I install the PKCS file through the WCS snap-in, I can access the "PrivateKey" data member in the object. Otherwise, I cannot. I am loading the key with the following:

    $target_certificate = Import-PfxCertificate `
        -CertStoreLocation 'Cert:\LocalMachine\My' `
        -FilePath '.\foo.pfx' `
        -Exportable

    I am running the following to retrieve the key.

    $target_certificate = Get-ChildItem 'Cert:\LocalMachine\My' `
        | Where-Object { $(Get-Date) -gt $(Get-Date $_.NotBefore)  `
            -and $(Get-Date) -lt $(Get-Date $_.NotAfter) `
            -and $_.EnhancedKeyUsageList.ObjectId -contains '1.3.6.1.5.5.7.3.1' `
            -and $_.Subject -match "CN=${target_machine_hostname}" }

    I think this is a bug.


    Adam

    Monday, April 16, 2018 7:07 PM