Set TLS certificate for standalone service fabric cluster using Windows security

Hi Marbry,

Thanks for the follow-up, and glad the HTTPS part is working! The client certificate prompt you're seeing is actually a well-understood behavior in this hybrid configuration, and the fix is straightforward — let me walk you through it.

Cause :

The issue is with the ServerCredentialType value in your ClusterConfig.json. When ServerCredentialType is set to "Windows", the HTTP gateway expects clients to authenticate using Windows/Kerberos credentials. However, once you add a ServerCertificate to the CertificateInformation block, Service Fabric internally treats the HTTPS endpoint as requiring mutual TLS — which causes the browser to prompt for a client certificate before Windows auth even gets a chance to kick in.

In other words: the ServerCredentialType is controlling how clients authenticate to the management API, not just whether TLS is used for transport. Because you want TLS on the wire but Windows auth for identity, these two settings need to be aligned correctly.

Fix :

The documented approach for this scenario is to set ServerCredentialType to "X509" (to tell Service Fabric to use the server certificate for the HTTPS binding), while keeping ClusterCredentialType as "Windows" (to preserve Windows/gMSA-based node-to-node auth). You then also need to add a ClientCertificateThumbprints entry so that authorized Windows clients can be mapped through.

However — and this is the important part — if your goal is purely to have HTTPS on the Explorer/management endpoint without requiring a client certificate from the browser, the cleanest approach is to ensure that your browser has access to a client certificate that is listed in ClientCertificateThumbprints. Service Fabric Explorer, when the cluster uses X509 for ServerCredentialType, expects the client (browser) to present a cert to authenticate. This is by design.

Here's the revised security section that reflects the correct hybrid setup:

"security": {

"ClusterCredentialType": "Windows",

"ServerCredentialType": "X509",

"WindowsIdentities": {

"ClustergMSAIdentity": "yourdomain\\YourGmsaAccount",

"ClusterSPN": "http/servicefabric/clusterA.contoso.com",

"ClientIdentities": [

 { "Identity": "CONTOSO\\adminuser", "IsAdmin": true }

]

},

"CertificateInformation": {

"ServerCertificateCommonNames": {

 "CommonNames": [

 { "CertificateCommonName": "your-cluster-fqdn.contoso.com" }

 ],

 "X509StoreName": "My"

},

"ClientCertificateThumbprints": [

 {

 "CertificateThumbprint": "<YourAdminClientCertThumbprint>",

 "IsAdmin": true

 }

]

}

}

1. Provision a client certificate for the administrator This can be the same cert as the server cert (for test/dev) or a separate cert. Install it into the Current User > Personal store on the machine you're browsing from.
2. Update ClusterConfig.json
   • Set ServerCredentialType to "X509"
   • Add the ClientCertificateThumbprints entry (as shown above) with the thumbprint of your admin client certificate
3. Apply the config change If the cluster is already running, apply via: .\UpdateServiceFabricCluster.ps1 -ClusterConfigFilePath .\ClusterConfig.json
4. Import the client cert into your browser On Windows, if the cert is installed in the Current User Personal store, Edge/Chrome will pick it up automatically. You'll still get a prompt to select the certificate — that's expected browser behavior when the server requests mutual TLS.

• The client certificate prompt from the browser is expected when ServerCredentialType is X509. There is no way to bypass it entirely while keeping HTTPS — the server is signaling that it wants to authenticate the client. If you select the right certificate, the Windows ClientIdentities will still control authorization inside Service Fabric.

• Per the documentation: "If you specify a server certificate for outside connections, set the ServerCredentialType to X509." Setting it to Windows while also providing a ServerCertificate is what's causing the mismatch you're seeing.

• ClusterCredentialType (Windows/gMSA) and ServerCredentialType (X509) can be mixed — these are independent settings controlling different authentication paths.

Thanks,
Manish

OK, so there's basically no way to accomplish that without a client certificate?

If i undrrstand correctly the client certificate would have to be deployed on any Windows instance an admin user was accessing explorer from, but they're also still authorized against the list of admin user accounts? So that would give us https connections and Windows authentication and authorization of the admins?

That's one of the things I was trying to avoid, creating a new requirement for configuration outside of the servers themselves. But at least it's confined to a small population.