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.