{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-455-do-not-assume-every-service-fabric-node-retains-the-same-old-certificates/", "item": { "id": "https://update.dsesecurity.com/updates/dse-20260909-455-do-not-assume-every-service-fabric-node-retains-the-same-old-certificates/", "slug": "dse-20260909-455-do-not-assume-every-service-fabric-node-retains-the-same-old-certificates", "url": "https://update.dsesecurity.com/updates/dse-20260909-455-do-not-assume-every-service-fabric-node-retains-the-same-old-certificates/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-455-do-not-assume-every-service-fabric-node-retains-the-same-old-certificates.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-455-do-not-assume-every-service-fabric-node-retains-the-same-old-certificates/" }, "title": "Do not assume every Service Fabric node retains the same old certificates", "summary": "Certificate rotation through the Key Vault VM extension can leave different certificate histories on existing and newly added nodes.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:24:21+00:00", "modified_at": "2026-09-10T02:08:04+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 246, "potentially_affected": "Service Fabric clusters provisioning certificates through the Key Vault VM extension.", "dse_recommendation": "Compare certificate inventories across existing, newly scaled and reimaged nodes before relying on an older certificate.", "primary_source": { "name": "Manage certificates in a Service Fabric cluster - Azure Service Fabric | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/service-fabric/cluster-security-certificate-management", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source facts

\n

The Key Vault VM extension retrieves and installs the current certificate version without removing existing certificates. Older versions can therefore remain on an existing node while a newly added scale-set node receives only the current version. Reimaging resets the store to the operating-system image and implicitly removes the earlier versions.

\n

Service Fabric itself does not delete a user-declared certificate. For certificates provisioned as VM or scale-set secrets, deleting the referenced vault item or disabling its referenced version can make later deployments fail. Microsoft Learn.

\n

Applicability

\n

Identify the provisioning mechanism for each certificate before applying these behaviors. Do not infer a node’s certificate history from a successful cluster-wide rotation status or assume a particular reimaging schedule.

\n

DSE recommendation

\n

DSE recommends including both long-lived and newly created nodes in certificate dependency reviews. If an application still needs an earlier certificate, investigate that dependency explicitly rather than relying on its accidental persistence. Keep cleanup decisions separate from rotation completion and review deployment references before changing vault items.

\n

Verification

\n

Compare certificate identifiers and required application access on representative existing, scale-out and reimaged test nodes. Check the current deployment declarations alongside the inventories. Record which version each workload actually needs without collecting private keys. Approve cleanup only after the relevant owners have resolved dependencies and tested the intended lifecycle; finding an old certificate on one machine is not evidence that it will survive replacement elsewhere.

\n

Official references

\n

Microsoft Learn: Manage certificates in a Service Fabric cluster. Source retrieved September 9, 2026.

", "content_text": "Source facts\nThe Key Vault VM extension retrieves and installs the current certificate version without removing existing certificates. Older versions can therefore remain on an existing node while a newly added scale-set node receives only the current version. Reimaging resets the store to the operating-system image and implicitly removes the earlier versions.\nService Fabric itself does not delete a user-declared certificate. For certificates provisioned as VM or scale-set secrets, deleting the referenced vault item or disabling its referenced version can make later deployments fail. Microsoft Learn.\nApplicability\nIdentify the provisioning mechanism for each certificate before applying these behaviors. Do not infer a node’s certificate history from a successful cluster-wide rotation status or assume a particular reimaging schedule.\nDSE recommendation\nDSE recommends including both long-lived and newly created nodes in certificate dependency reviews. If an application still needs an earlier certificate, investigate that dependency explicitly rather than relying on its accidental persistence. Keep cleanup decisions separate from rotation completion and review deployment references before changing vault items.\nVerification\nCompare certificate identifiers and required application access on representative existing, scale-out and reimaged test nodes. Check the current deployment declarations alongside the inventories. Record which version each workload actually needs without collecting private keys. Approve cleanup only after the relevant owners have resolved dependencies and tested the intended lifecycle; finding an old certificate on one machine is not evidence that it will survive replacement elsewhere.\nOfficial references\nMicrosoft Learn: Manage certificates in a Service Fabric cluster. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nThe Key Vault VM extension retrieves and installs the current certificate version without removing existing certificates. Older versions can therefore remain on an existing node while a newly added scale-set node receives only the current version. Reimaging resets the store to the operating-system image and implicitly removes the earlier versions.\n\nService Fabric itself does not delete a user-declared certificate. For certificates provisioned as VM or scale-set secrets, deleting the referenced vault item or disabling its referenced version can make later deployments fail. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/service-fabric/cluster-security-certificate-management).\n\n## Applicability\n\nIdentify the provisioning mechanism for each certificate before applying these behaviors. Do not infer a node’s certificate history from a successful cluster-wide rotation status or assume a particular reimaging schedule.\n\n## DSE recommendation\n\nDSE recommends including both long-lived and newly created nodes in certificate dependency reviews. If an application still needs an earlier certificate, investigate that dependency explicitly rather than relying on its accidental persistence. Keep cleanup decisions separate from rotation completion and review deployment references before changing vault items.\n\n## Verification\n\nCompare certificate identifiers and required application access on representative existing, scale-out and reimaged test nodes. Check the current deployment declarations alongside the inventories. Record which version each workload actually needs without collecting private keys. Approve cleanup only after the relevant owners have resolved dependencies and tested the intended lifecycle; finding an old certificate on one machine is not evidence that it will survive replacement elsewhere.\n\n## Official references\n\n[Microsoft Learn: Manage certificates in a Service Fabric cluster](https://learn.microsoft.com/en-us/azure/service-fabric/cluster-security-certificate-management). Source retrieved September 9, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/dse-20260909-455-do-not-assume-every-service-fabric-node-retains-the-same-old-certificates/", "url": "https://update.dsesecurity.com/updates/dse-20260909-455-do-not-assume-every-service-fabric-node-retains-the-same-old-certificates/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-09-09" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/dse-20260909-455-do-not-assume-every-service-fabric-node-retains-the-same-old-certificates/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Do not assume every Service Fabric node retains the same old certificates", "item": "https://update.dsesecurity.com/updates/dse-20260909-455-do-not-assume-every-service-fabric-node-retains-the-same-old-certificates/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/dse-20260909-455-do-not-assume-every-service-fabric-node-retains-the-same-old-certificates/#article", "identifier": "https://update.dsesecurity.com/updates/dse-20260909-455-do-not-assume-every-service-fabric-node-retains-the-same-old-certificates/", "url": "https://update.dsesecurity.com/updates/dse-20260909-455-do-not-assume-every-service-fabric-node-retains-the-same-old-certificates/", "headline": "Do not assume every Service Fabric node retains the same old certificates", "description": "Certificate rotation through the Key Vault VM extension can leave different certificate histories on existing and newly added nodes.", "abstract": "Certificate rotation through the Key Vault VM extension can leave different certificate histories on existing and newly added nodes.", "articleBody": "Source facts\nThe Key Vault VM extension retrieves and installs the current certificate version without removing existing certificates. Older versions can therefore remain on an existing node while a newly added scale-set node receives only the current version. Reimaging resets the store to the operating-system image and implicitly removes the earlier versions.\nService Fabric itself does not delete a user-declared certificate. For certificates provisioned as VM or scale-set secrets, deleting the referenced vault item or disabling its referenced version can make later deployments fail. Microsoft Learn.\nApplicability\nIdentify the provisioning mechanism for each certificate before applying these behaviors. Do not infer a node’s certificate history from a successful cluster-wide rotation status or assume a particular reimaging schedule.\nDSE recommendation\nDSE recommends including both long-lived and newly created nodes in certificate dependency reviews. If an application still needs an earlier certificate, investigate that dependency explicitly rather than relying on its accidental persistence. Keep cleanup decisions separate from rotation completion and review deployment references before changing vault items.\nVerification\nCompare certificate identifiers and required application access on representative existing, scale-out and reimaged test nodes. Check the current deployment declarations alongside the inventories. Record which version each workload actually needs without collecting private keys. Approve cleanup only after the relevant owners have resolved dependencies and tested the intended lifecycle; finding an old certificate on one machine is not evidence that it will survive replacement elsewhere.\nOfficial references\nMicrosoft Learn: Manage certificates in a Service Fabric cluster. Source retrieved September 9, 2026.", "datePublished": "2026-09-10T00:24:21+00:00", "dateModified": "2026-09-10T02:08:04+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/dse-20260909-455-do-not-assume-every-service-fabric-node-retains-the-same-old-certificates/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/dse-20260909-455-do-not-assume-every-service-fabric-node-retains-the-same-old-certificates/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Do not assume every Service Fabric node retains the same old certificates" }, "articleSection": [ "Cybersecurity", "Networks & Infrastructure" ], "keywords": [ "Cybersecurity", "Networks & Infrastructure", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 246, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Manage certificates in a Service Fabric cluster - Azure Service Fabric | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/service-fabric/cluster-security-certificate-management" } } ] } }