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.<\/p>\n
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<\/em>) which accepts a parameter of type System.Security.Cryptography.X509Certificates.X509Certificate2<\/em>, i.e. a reference to the certificate you want to analyze.<\/p>\n I guess I do not need to mention that you can easily find the certificate you’re interested in by running something like<\/p>\n\r\nparam(\r\n [Parameter(Mandatory=$true)]\r\n [System.Security.Cryptography.X509Certificates.X509Certificate2]\r\n $Certificate\r\n)\r\n\r\necho "Looking for private key file of certificate"\r\necho $Certificate\r\necho ""\r\necho "The private key file is '$($Certificate.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName)'"\r\necho ""\r\n\r\n$file = ls $env:userprofile -Filter $Certificate.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName -Recurse -Force -EA SilentlyContinue\r\necho "It is located at '$($file.FullName)'."\r\n<\/pre>\n
\r\npushd cert:\\CurrentUser\\My\r\nls\r\n$cert = gci 0DAC31905AEB722D8561BFAF3F3BFD2F551AA197\r\npopd\r\n.\\FindPrivateKey.ps1 $cert\r\n<\/pre>\n