Managed Service Fabric and Certificate Wildcard Common Name

Question

I am trying to create a Managed Service Fabric cluster with a wildcard certificate common name. I've done this with unmanaged SF, but wanted to do so with Managed SF.

Question 1: Does Managed SF support certificate common name (with a wildcard)... ie.. "*.mydomain.com"

Question 2: If so, is this supported via Bicep templates? Arm? Another?

I have used the following link to set up unmanaged SF with a wildcard common name, but not all the fields are available in Bicep for Managed SF (the VM profile has a common name section).
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-create-cluster-using-cert-cn

Currently, my bicep template under Microsoft.ServiceFabric/managedClusters@2022-08-01-preview has:

clients: [  
      {  
        isAdmin: true  
        commonName: '*.mydomain.com'  
        issuerThumbprint: certificateThumbprint  
      }  
    ]  

I would expect the VM profile to have a place to specify a common name as well, but there does not appear to be one: https://learn.microsoft.com/en-us/azure/templates/microsoft.servicefabric/managedclusters/nodetypes?pivots=deployment-language-arm-template

Answer 1

@Smith, Joshua

Question : Does Managed SF support certificate common name (with a wildcard)?
If you are talking about the cluster certificate, then no. The Cluster certificate is completely managed by Azure.
But, the application certificate is owned by the customer.

To provide more clarity, the certification information provided in the 'clients' section of the template is for client certificates. These are certificates in customer's possession and can be used as credential to access the cluster. They don’t need to be installed on the cluster, the cluster only needs to know their definition and use those to authenticate the client connections.

The cluster certificate, on the other hand, is managed by Azure. When connecting to a managed SF cluster with Service Fabric PowerShell, customer needs to query the Azure managed cluster resource to get the details about the cluster certificate, and then use that as connection parameters. Please see Connect to a Service Fabric managed cluster for how to do that.

Answer 2

This makes sense. The only thing I found with the common name wildcard of the client certificate is that you have to set ALL fields in bicep in order to authenticate. In other words, the thumbprint field must be provided, even if commonName and issuerThumbprint is set. Otherwise you cannot connect to the cluster.

clients: [  
      {  
        isAdmin: true  
        commonName: certificateCommonName  
        issuerThumbprint: certificateThumbprint  
        thumbprint: certificateThumbprint  // must provide!  
      }  
    ]