Limitations in ADO Service Connection Thumbprint field

Thanks James - I have been trying to get the update using the REST API via Postman to prove out that it will work, but can't seem to get past error for fields (endpoint, source, etc) that are not documented but erroring as required - https://learn.microsoft.com/en-us/rest/api/azure/devops/serviceendpoint/endpoints?view=azure-devops-rest-7.1 - and don't show up in the GET either. I'm not sure if it is a limitation with Service Fabric Service Connection updates or something else.

I did go ahead and open a ticket as well requesting if that field could be extended.

Looks like the null parameter errors (initially endpoint) were because it didn't like breaking the thumbprints out like "thumb1","thumb2", etc in the json ... it wants it as one string - "thumb1,thumb2" etc which does align with the way you enter in the UI. Unfortunately, even the REST call hits an issue with it exceeding 7 thumbprints :-(

{

"$id": "1",

"innerException": null,

**"message": "The String length exceeds maximum limit.\r\nParameter name: endpoint.Authorization.Parameters[servercertthumbprint]",**

"typeName": "System.ArgumentException, mscorlib",

"typeKey": "ArgumentException",

"errorCode": 0,

"eventId": 0
```}

Hello Chad Cummings,

To work around the limit of 7 server certificate thumbprints per Azure DevOps Service Connection, you can create multiple Service Fabric Service Connections. Each connection will handle up to 7 thumbprints. The script below automates this process using the Azure DevOps REST API and Key Vault.

# Fetch thumbprints from Key Vault

$vaultName = "your-vault-name"

$certNames = @("cert1", "cert2", "cert3", "cert4", "cert5", "cert6", "cert7", "cert8") # Replace with your cert names

$thumbprints = $certNames | ForEach-Object { (Get-AzKeyVaultCertificate -VaultName $vaultName -Name $_).Thumbprint }

$thumbprintGroups = $thumbprints | Group-Object -Property { [math]::Floor([array]::IndexOf($thumbprints, $_) / 7) } | ForEach-Object { $_.Group -join "," }

# Azure DevOps REST API details

$pat = "your_personal_access_token"

$org = "your_organization"

$project = "your_project"

$apiVersion = "7.1-preview.4"

# Create Service Connections

$index = 1

foreach ($thumbprintGroup in $thumbprintGroups) {

    $body = @{

        name = "SFConnection-$index"

        type = "servicefabric"

        url = "tcp://your_cluster:19000"

        authorization = @{

            parameters = @{

                certlookup = "Thumbprint"

                servercertthumbprint = $thumbprintGroup

                certificate = "your_base64_encoded_client_cert" # Use: [System.Convert]::ToBase64String([System.IO.File]::ReadAllBytes("certificate.pfx"))

                certificatepassword = "your_cert_password"

            }

            scheme = "Certificate"

        }

        isShared = $true

        isReady = $true

        serviceEndpointProjectReferences = @(

            @{

                projectReference = @{

                    id = "your_project_id"

                    name = "your_project_name"

                }

                name = "SFConnection-$index"

            }

        )

    } | ConvertTo-Json -Depth 10

    $uri = "https://dev.azure.com/$org/$project/_apis/serviceendpoint/endpoints?api-version=$apiVersion"

    Invoke-RestMethod -Uri $uri -Method Post -Headers @{ Authorization = "Basic $([Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$pat")))"; "Content-Type" = "application/json" } -Body $body

    $index++

}

• Replace placeholders such as your-vault-name, your_organization, your_project, your_project_id, and certificate details with actual values.
• Run the PowerShell script to create multiple Service Connections, each with up to 7 thumbprints.
• Use these connections in your Azure DevOps pipelines.

Below is YAML example

parameters:

  - name: clusterName

    type: string

variables:

  serviceConnection: ${{ parameters.clusterName }}-SFConnection

steps:

  - task: ServiceFabricDeploy@1

    inputs:

      serviceConnectionName: $(serviceConnection)

• The script can be scheduled to run regularly or triggered by certificate rollover events to keep Service Connections updated.
• This method ensures each Service Connection respects the 7-thumbprint limit and automates the creation and maintenance of these connections please let me know If you need further assistance, please provide the comment.

Hi Bodapati Harish - thanks for the continued support on possible options.

I am struggling to see how this approach solves the problem caused by the thumbprint limitation? As it is currently, if any SF Cluster has 8 (or more) thumbprints and the service connection is missing any of them the connection fails with a cert not matched error.

If multiple service connections are created for ones that have 7+ then both of them won't have the complete set needed to validation the connection as you can't use two service connections as a group for one deploy, can you?

A little more background on how ours are used

1. We have nonProd SCs - sandbox, dev, test, uat
2. We have Prod SCs
3. We create all the SC's in a central ado Project and share to X number of projects that need them
   1. So, we have X number of projects with X number pipelines (YAML and Classic) with these connections coded or pre-selected (classic dropdown list)

So, a potential workaround would to:

1. Pull the thumbprints dynamically from each cluster (X nonprod, X prod)
2. Create or update the same a service connection of the same name in order to not break X number of pipelines using the connection(s)

Or given the limitation we are seeing in the Service Connection approach is there a mix in your approach(es) using key vault and some existing/combination of a ADO Task(s) to connect to a Service Fabric with a provided set of thumbprints in order to perform a deployment?

Hello Chad Cummings,

You're absolutely right about the core limitation: with the 7-thumbprint cap on the Service Fabric service connection, any cluster with 8 or more certs poses a problem, and there's no built-in support for grouping multiple service connections in a single deployment.

To work around this, we're proposing a dynamic update model, where a script or automation task periodically:

• Pulls the active thumbprints directly from each SF cluster (both non-prod and prod)
• Replaces the thumbprint list in the existing service connection (keeping the name and ID unchanged)

This way, we ensure that the service connection always reflects the current and valid set of certs without requiring pipeline changes or creating multiple service connections per cluster. Since you're using shared service connections across many pipelines and projects, keeping the SC identity intact is key to avoiding disruptions.

This approach does not technically increase the 7-thumbprint limit, but by keeping the SC updated with only the currently needed certs, we avoid mismatches and minimize the risk of failure. In clusters where more than 7 are active, you'd prioritize only those required for the specific deployment window (for example, certs that are active and not expired/soon-to-expire).

As an optional enhancement, we’re also evaluating use of Azure Key Vault for centralized cert tracking, or possibly leveraging CN-based authentication where suitable, to bypass the thumbprint limitation entirely.

Please let me know if you have any further question, I'll happy to assist you.

Hello Chad Cummings,

Following up to see if you have chance to check the previous response and help us with requested information to check and assist you further on this.

Hello Chad Cummings,

We haven’t heard from you on the last response and was just checking back to see could you please provide more details on your requirement so that I can assist you further.

Hi Bodapati - we are trying to pursue your suggestion on dynamic pulling of the thumbprints for the Service Fabric. While I did open a support to expand the UI field, it will still need automation if those thumbprints change periodically.

Right now, I am blocked internally with requirements to another team to create a custom role so my SP can talk to the Service Fabric cluster.

From the errors I am getting and researching around, it seems that the below actions are needed to pull the SF thumbprints. Reader, Contributor, etc don't have these abilities, nor do any others that I saw in our listings

"Actions": [

"Microsoft.ServiceFabric/clusters/read",

"Microsoft.ServiceFabric/clusters/applications/read",

"Microsoft.ServiceFabric/clusters/services/read"

]

Will advise once I get this role created.

I did manually test your point though about certs likely not all needed - some expired or soon to be - as I removed the first thumbprint in the list and included the next 7 and the service connection worked. I don't understand why Microsoft doesn't cleanup the ones they manage as there is no notice to our Cloud team when they add new thumbprints, but I'll ask that question on my open support ticket.

Hello Chad Cummings,

Thanks for the update! For the custom role, you’re on the right track with those permissions (Microsoft.ServiceFabric/clusters/read, Microsoft.ServiceFabric/clusters/applications/read, Microsoft.ServiceFabric/clusters/services/read). You might also need Microsoft.ServiceFabric/clusters/list to fully query cluster details. Here’s a quick role template to share with your team:

{

  "properties": {

    "roleName": "ServiceFabricThumbprintReader",

    "description": "Read Service Fabric cluster thumbprints",

    "assignableScopes": ["/subscriptions/your-subscription-id"],

    "permissions": [

      {

        "actions": [

          "Microsoft.ServiceFabric/clusters/read",

          "Microsoft.ServiceFabric/clusters/list",

          "Microsoft.ServiceFabric/clusters/applications/read",

          "Microsoft.ServiceFabric/clusters/services/read"

        ],

        "notActions": [],

        "dataActions": [],

        "notDataActions": []

      }

    ]

  }

}

Once the role is set, you can pull thumbprints from the cluster and update your Service Connections automatically. Here’s a short PowerShell script to do that, keeping the same Service Connection names so your pipelines don’t break:

$clusterEndpoint = "tcp://your-cluster:19000"

$serviceConnectionName = "Sandbox-SC"

$pat = "your_personal_access_token"

$org = "your_organization"

$project = "your_project"

$clientCertPath = "path-to-client-cert.pfx"

$certPassword = "your_cert_password"

# Get thumbprints from cluster

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($clientCertPath, $certPassword)

$uri = "https://$($clusterEndpoint -replace 'tcp','https')/ClusterCertificates"

$response = Invoke-RestMethod -Uri $uri -Method Get -Headers @{ "Authorization" = "Bearer $cert" } -Certificate $cert

$thumbprints = $response.Certificates | Sort-Object NotAfter -Descending | Select-Object -First 7 -ExpandProperty Thumbprint | Join-String -Separator ","

# Update Service Connection

$uriGet = "https://dev.azure.com/$org/$project/_apis/serviceendpoint/endpoints?api-version=7.1-preview.4"

$endpoints = Invoke-RestMethod -Uri $uriGet -Method Get -Headers @{ Authorization = "Basic $([Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$pat")))"; "Content-Type" = "application/json" }

$endpointId = ($endpoints.value | Where-Object { $_.name -eq $serviceConnectionName }).id

$body = @{

    name = $serviceConnectionName

    type = "servicefabric"

    url = $clusterEndpoint

    authorization = @{

        parameters = @{

            certlookup = "Thumbprint"

            servercertthumbprint = $thumbprints

            certificate = [System.Convert]::ToBase64String([System.IO.File]::ReadAllBytes($clientCertPath))

            certificatepassword = $certPassword

        }

        scheme = "Certificate"

    }

    isShared = $true

    isReady = $true

    serviceEndpointProjectReferences = @(

        @{

            projectReference = @{

                id = "your_project_id"

                name = "your_project_name"

            }

            name = $serviceConnectionName

        }

    )

} | ConvertTo-Json -Depth 10

Invoke-RestMethod -Uri "https://dev.azure.com/$org/$project/_apis/serviceendpoint/endpoints/$endpointId?api-version=7.1-preview.4" -Method Put -Headers @{ Authorization = "Basic $([Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$pat")))"; "Content-Type" = "application/json" } -Body $body

This script grabs the 7 newest thumbprints from the cluster and updates the Service Connection without changing its name. Run it in a scheduled pipeline to keep things current.

If you have a cluster with 8+ active thumbprints that all need to be used, the Service Connection won’t work due to the 7-thumbprint limit. In that case, switch to the ServiceFabricPowerShell@1 task to deploy directly, passing all thumbprints. Example for YAML:

steps:

  - powershell: |

      $clusterEndpoint = "tcp://your-cluster:19000"

      $certPath = "path-to-client-cert.pfx"

      $certPassword = "your_cert_password"

      $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certPath, $certPassword)

      $uri = "https://$($clusterEndpoint -replace 'tcp','https')/ClusterCertificates"

      $response = Invoke-RestMethod -Uri $uri -Method Get -Headers @{ "Authorization" = "Bearer $cert" } -Certificate $cert

      $thumbprints = $response.Certificates | Select-Object -ExpandProperty Thumbprint | Join-String -Separator ","

      Write-Output "##vso[task.setvariable variable=Thumbprints]$thumbprints"

    displayName: 'Get Thumbprints'

  - task: ServiceFabricPowerShell@1

    inputs:

      clusterConnectionParameters: |

        @{

          ConnectionEndpoint = "tcp://your-cluster:19000"

          CertificateThumbprint = "$(Thumbprints)"

          ClientCertificate = @{

            Thumbprint = "your_client_cert_thumbprint"

            StoreLocation = "LocalMachine"

            StoreName = "My"

          }

        }

      scriptType: 'Inline'

      inline: |

        Connect-ServiceFabricCluster @ClusterConnectionParameters

        Publish-NewServiceFabricApplication -ApplicationPackagePath '$(Build.ArtifactStagingDirectory)/pkg' -ApplicationName 'fabric:/MyApp' -OverwriteBehavior 'Always'

      overrideClusterConnectionParameters: true

For Classic pipelines, add a PowerShell task to set the thumbprints variable, then configure ServiceFabricPowerShell@1 with the same parameters.