Set TLS certificate for standalone service fabric cluster using Windows security

Question

How do we define a certificate for HTTPS communication within a standalone service fabric cluster and service fabric explorer if we're using the Windows credential type?

This seems like it should be two separate things, but I don't see anywhere separate from the cluster and server certs to define that. And you can't have both CertificateInformation and WindowsIdentities sections in the config.

Does this mean that if you use the Windows credential type, you have to use only HTTP rather than HTTPS? Which doesn't seem to make much sense, so I assume there must be some way to do it.

Answer 1

Hi Marbry,

Thank you for the clear description of your standalone Service Fabric cluster configuration question. This is a common point of confusion when mixing Windows credential type with HTTPS requirements for Service Fabric Explorer and the management API.

• WindowsIdentities (under the security section) controls authentication and authorization — it defines which domain accounts or gMSA identities can connect to the cluster and which have admin rights.
• The TLS/HTTPS layer for the management endpoint (port 19080) and Service Fabric Explorer is handled separately by the server certificate.
• You do not need to use only HTTP. HTTPS is fully supported (and recommended for production) even when ClusterCredentialType is set to Windows.
• The CertificateInformation section is used only when a credential type is X509. When using Windows security you configure the HTTPS certificate differently — specifically by setting ServerCredentialType to X509 and placing the server certificate details in the appropriate location in ClusterConfig.JSON. This keeps the two concerns cleanly separated.

Links :
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-windows-cluster-windows-security

https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-windows-cluster-x509-security

Steps to work on

• Open your ClusterConfig.JSON file (the one you use with CreateServiceFabricCluster.ps1 or TestConfiguration.ps1).
• In the top-level security section, configure it like this (mixed credential types are fully supported):

    "security": {
      "ClusterCredentialType": "Windows",
      "ServerCredentialType": "X509",
      "WindowsIdentities": {
        "ClusterIdentity": "domain\\machinegroup",   // or use ClustergMSAIdentity + ClusterSPN
        "ClientIdentities": [
          {
            "Identity": "domain\\username",
            "IsAdmin": true
          }
        ]
      },
      "CertificateInformation": {
        "ServerCertificate": {
          "Thumbprint": "your-server-cert-thumbprint-here",
          "X509StoreName": "My",
          "X509StoreLocation": "LocalMachine"
        }
      }
    }
  

• Make sure the server certificate (with the private key) is installed in the Local Computer \ Personal store on every node in the cluster, and that the NETWORK SERVICE account has read access to the private key.
• Validate and deploy/upgrade the configuration:

    .\TestConfiguration.ps1 -ClusterConfigFilePath .\ClusterConfig.JSON
    .\CreateServiceFabricCluster.ps1 -ClusterConfigFilePath .\ClusterConfig.JSON -AcceptEULA
  

• After the cluster is up, access Service Fabric Explorer using HTTPS on port 19080. The connection will be TLS-secured by the server certificate you just configured, while authentication and admin rights continue to be enforced via your Windows identities.

This approach gives you the best of both worlds: Windows-based authentication (no client certificates required) + proper TLS encryption for all management traffic and Explorer.

If you run into any validation errors during TestConfiguration or deployment, feel free to reply here with the exact error.

Thanks,
Manish.

Answer 2

I think https stays fine… windowsIdentities never enters the tls path, the only failure point is the cert bind. just put ur https cert in Cluster/ServerCertificate and let sf read the thumbprint… that’s all that actually flips it.