How Do You Handle Multiple Server Certificate Thumbprints in Azure Service Fabric Managed Clusters?
Hi everyone, I wanted to share a common challenge we’ve encountered in DevOps pipelines when working with Azure Service Fabric Managed Clusters (SFMC) — and open it up for discussion to hear how others are handling it. 🔍 The Issue When retrieving the cluster certificate thumbprints using PowerShell: (Get-AzResource -ResourceId "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RG_NAME>/providers/Microsoft.ServiceFabric/managedclusters/<CLUSTER_NAME>").Properties.clusterCertificateThumbprints …it often returns multiple thumbprints. This typically happens due to certificate renewals or rollovers. Including all of them in your DevOps configuration isn’t practical. ✅ What Worked for Us We’ve had success using the last thumbprint in the list, assuming it’s the most recently active certificate: (Get-AzResource -ResourceId "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RG_NAME>/providers/Microsoft.ServiceFabric/managedclusters/<CLUSTER_NAME>").Properties.clusterCertificateThumbprints | Select-Object -Last 1 This approach has helped us maintain stable and secure connections in our pipelines. 🔍 Solution 2: Get current Server Certificate You can also verify the active certificate using OpenSSL: openssl s_client -connect <MyCluster>.<REGION>.cloudapp.azure.com:19080 -servername <MyCluster>.<REGION>.cloudapp.azure.com | openssl x509 -noout -fingerprint -sha1 🛠️ Tip for New Deployments If you're deploying a new SFMC, consider setting the following property in your ARM or Bicep template: "autoGeneratedDomainNameLabelScope": "ResourceGroupReuse" This ensures the domain name is reused within the resource group, which helps reduce certificate churn and keeps the thumbprint list clean and manageable. ⚠️ Note: This setting only applies during initial deployment and cannot be retroactively applied to existing clusters.Guidance for Certificate Use in CI/CD Pipelines for Service Fabric
In non-interactive CI/CD scenarios where certificates are used to authenticate with Azure Service Fabric, consider the following best practices: Use Admin Certificates Instead of Cluster Certificates Cluster certificates are used for node-to-node and cluster-level authentication and are highly privileged. For CI/CD pipelines, prefer using a dedicated Admin client certificate: Grants administrative access only at the client level. Limits the blast radius in case of exposure. Easier to rotate or revoke without impacting cluster internals. Best practices to protect your service fabric certificates: - Provision a dedicated Service Fabric Admin certificate specifically for the CI/CD pipeline instead of cluster certificate. This certificate should not be reused across other services or users. - Restrict access to this certificate strictly to the pipeline environment. It should never be distributed beyond what is necessary. - Secure the pipeline itself, as it is part of the cluster’s supply chain and a high-value target for attackers. - Implement telemetry and monitoring to detect potential exposure—such as unauthorized access to the CI/CD machine or unexpected distribution of the certificate. - Establish a revocation and rotation plan to quickly respond if the certificate is compromised.
Azure Logic Apps : HTTP Request OR Custom Connector
Hello, As far as I know, We use HTTP requests while consuming the First-party/third-party API, then when should we use a custom connector? What are those business cases where one should use an HTTP request in PowerAutomate and use in PowerApps Or use a custom connector and use in PowerApps and Power Automate? What are the pros and cons of HTTP Request OR Custom Connector? Thanks and Regards, -Sri