Securing Service Fabric Cluster with Certificate Common Names

Published 08-06-2019 04:02 PM 567 Views
Senior Member
First published on MSDN on Apr 27, 2018
Managing secrets in Service Fabric is now much easier with the ability to manage them using common names. Gone are the days of the repetitive dreadful thumbprint updating! To dive right in - head over to our Create new cluster using certificate common name , Change cluster from certificate thumbprint to common name , Manually rollover a Service Fabric Cluster certificate , and Connect to a secure cluster documentation.

Key impact: improved secrets management experience and an elimination of template version changes to update certificate thumbprints

Being responsible for secrets management in a Service Fabric cluster requires timely changes and updates, and commonly results in production service outages; resulting from of expired secrets or incorrect configurations during changes. Even if you are a Secrets Management expert, changing a certificate thumbprint that is just a string of numbers and letters, exposes production services to avoidable outages. Our team has worked hard to change this experience, and eliminate the need to ever update your templates certificate thumbprint again, by instead managing certificates through their common names.

Delivering this feature required us to implement a new algorithm to determine which available certificate has an expiration date furthest into the future, in absence of an explicitly defined certificate thumbprint for the certificate to be used to secure your cluster. This means that automagically, your KeyVault certificate with the furthest into the future expiring date that matches the common name defined within your template, will be installed and used by your cluster. You simply add a new certificate with the same common name to your KeyValue and VM Scale Set, and then update your VM Scale set to use our algorithm and deploy the updated certificate; NO Thumbprint changes!!! Given self-signed certificates cannot be securely verified, this feature is only applicable to clusters who use CA issued certificates, and thus doesn’t work with self-signed certificates created either through Azure Portal or through our PowerShell modules.
Version history
Last update:
‎Aug 06 2019 04:02 PM
Updated by: