At work, I have created multiple tools which we used to analyse and fix issues related to certificates that we use with Office Communications Server and their respective private key files. To summarize, a user/service who wants to use the certificate for authentication needs to have read access on the private key. If it doesn’t, you’ll typically see a strange error which many people don’t relate to missing ACLs on the private key file.
Now these days, you don’t need to write such tools anymore. PowerShell allows you to pretty much do everything you need in this area. Let’s look at the following PS script (let’s call it FindPrivateKey.ps1) which accepts a parameter of type System.Security.Cryptography.X509Certificates.X509Certificate2, i.e. a reference to the certificate you want to analyze.
param( [Parameter(Mandatory=$true)] [System.Security.Cryptography.X509Certificates.X509Certificate2] $Certificate ) echo "Looking for private key file of certificate" echo $Certificate echo "" echo "The private key file is '$($Certificate.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName)'" echo "" $file = ls $env:userprofile -Filter $Certificate.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName -Recurse -Force -EA SilentlyContinue echo "It is located at '$($file.FullName)'."
I guess I do not need to mention that you can easily find the certificate you’re interested in by running something like
pushd cert:\CurrentUser\My ls $cert = gci 0DAC31905AEB722D8561BFAF3F3BFD2F551AA197 popd .\FindPrivateKey.ps1 $cert
where ‘0DAC31905AEB722D8561BFAF3F3BFD2F551AA197’ is simply the thumbprint of the certificate we’re interested in. From here on it should be easy to check what ACLs the file has (run $file.GetAccessControl()) and to modify them (run $file.SetAccessControl()).