Import-Exchange Certificate Ignores Path Provided

On an Exchange 2007 SP3 RU15 server, experienced an issue where the path statement on the Import-ExchangeCertificate cmdlet seemed to ignore what it was told to do….

The below PowerShell commands were used:

$Creds = Get-Credential

Import-ExchangeCertificate -Path .cert.pfx -Password $Creds.Password

Which generated an error stating “Import-ExchangeCertificate : The import file name .cert.pfx was not found or was not accessible”. 

Import-ExchangeCertificate : The Import File Name  Was Not Found Or Was Not Accessible

The file is not there, really?  That is not the case, it is highlighted in the above yellow box.  Time to crack out Process Monitor to see what PowerShell is touching on the file system.


Exchange 2007 Import-ExchangeCertificate

Interestingly there were no access denied messages, but look where PowerShell was trying to locate the PFX file. Only in the System32 directory…

Import-Exchange Certificate Looking In the Wrong Directory

Now, we can copy the certificate file to the C:WindowsSystem32 folder and the import will work but that is not clean.  Have I not used this command in the past 9 years to import certificates???

Time to review the help!

Exchange 2007 Import-ExchangeCertificate Help

Ah ha!  Note that the path specified is of type C:CertsCert.pfx.  It is NOT using the .Certscert.pfx syntax. 

Time for do-over!

Exchange 2007 Import-ExchangeCertificate Succesfully Imported Using Full Path To File

Much better this time.

I also do not feel dirty by coping files into the System32 folder!  Out of curiosity, does Exchange 2010 have the same behaviour?


Exchange 2010 Import-ExchangeCertificate

In a nutshell – no.  Exchange 2010 happily imports the certificate file when told to use .Cert.pfx. 

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path .Cert.pfx -Encoding byte -ReadCount 0)) -Password:$Creds.Password

Exchange 2010 implements PowerShell in a different way since it uses PowerShell remoting.  Because of this there are two PowerShell runspaces, one on the server and one on the client.  This is the reason that the client’s local drive is not directly accessible by the Exchange server, and the file contents must be saved into a byte array, which is then accessible to the Exchange server.  In this case Get-Content is used to parse the local certificate file which is probably why we do not have the same issue. 



Rhoderick Milne [MSFT]

Leave a Reply

Your email address will not be published. Required fields are marked *