I\'m calling a WCF service over HTTPS. => The certificates are ok. See screenshot:
The client certificates are installed under my account and local computer. Both avai
The problem was that network service account did not have the correct access rights to access the private key of the certificate.
You can solve this in 2 ways.
First one use powershell and a setup.bat to install and configure the certificates.
In your service fabric service add Setup.bat in the root of the project. Edit the service manifest and add a setup entry point
<ExeHost> <Program>Setup.bat</Program> <WorkingFolder>CodePackage</WorkingFolder> </ExeHost>
The bat file should probably run with elevated trust. You can add the following in the Application Manifest Inside the ServiceManifestImport:
<Policies> <RunAsPolicy CodePackageRef="Code" UserRef="SetupAdminUser" EntryPointType="Setup" /> </Policies>
At the bottom of the application manifest (in the root of the xml) add the following to run as admin.
<Principals> <Users> <User Name="SetupAdminUser"> <MemberOf> <SystemGroup Name="Administrators" /> </MemberOf> </User> </Users> </Principals>
The bat file is simple:
powershell.exe -ExecutionPolicy Bypass -Command ".\Scripts\Install-Certificates.ps1"
The powershell script can look like this
$pwd = ConvertTo-SecureString -String "YourPassword" -Force -AsPlainText
function Set-CertificatePermission
{
param
(
[Parameter(Position=1, Mandatory=$true)]
$cert ,
[Parameter(Position=2, Mandatory=$true)]
[ValidateNotNullOrEmpty()]
[string]$serviceAccount
)
# Specify the user, the permissions and the permission type
$permission = "$($serviceAccount)","Read,FullControl","Allow"
$accessRule = New-Object -TypeName System.Security.AccessControl.FileSystemAccessRule -ArgumentList $permission;
# Location of the machine related keys
$keyPath = $env:ProgramData + "\Microsoft\Crypto\RSA\MachineKeys\";
$keyName = $cert.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName;
$keyFullPath = $keyPath + $keyName;
try
{
# Get the current acl of the private key
$acl = (Get-Acl $keyFullPath)
# Add the new ace to the acl of the private key
$acl.AddAccessRule($accessRule);
# Write back the new acl
Set-Acl -Path $keyFullPath -AclObject $acl;
}
catch
{
throw $_;
}
}
function Install-RootCA($path){
Write-Host "Installing root certificate"
Import-PfxCertificate -FilePath $path -CertStoreLocation "Cert:\LocalMachine\Root" -Password $pwd -Exportable
}
function Install-Certificate($path){
Write-Host "Installing certificate"
$cert = Import-PfxCertificate -FilePath $path -CertStoreLocation "Cert:\LocalMachine\My" -Password $pwd -Exportable
Set-CertificatePermission $cert "NT AUTHORITY\NETWORK SERVICE"
}
Install-RootCA ".\Certificates\CARoot.pfx"
Install-Certificate ".\Certificates\ClientCert.pfx"
This will install a certificate in the trusted root store (because we use self signed certificates) and install a certificate in the Personal store of the computer account. The important bit for Service Fabric is it also sets correct rights on the private key for network service to access it.
Second method: manuel using mmc
There is a 3rd way that is simpler than the above ones which should work for WCF. If this service is running under the Network Service account, then you can put "protocol=https" in the service Endpoint declaration like this, which will do the acling;
<Resources>
<Endpoints>
<Endpoint Name="ServiceEndpoint" Protocol="https" />
</Endpoints>
Optionally you can return a certificate to the client and also run this service under a different security privilege. See here for more details https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-application-runas-security#assign-a-security-access-policy-for-http-and-https-endpoints