# Update Linux certificate consumers for the Key Vault extension's split-file format

> What must change in an application that expects one combined certificate-and-key file when moving to extension 4.x?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-331-update-linux-certificate-consumers-for-the-key-vault-extension-s-split-file-format/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:26:25+00:00
- Modified: 2026-09-10T01:40:03+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

What must change in an application that expects one combined certificate-and-key file when moving to extension 4.x?

## Potentially affected

Linux certificate consumers moving from Azure Key Vault VM extension 3.0 to 4.x on a documented supported distribution.

## DSE recommendation

Map the application's chain path, private-key path, reload signal, and file-reading identity before upgrading the extension.

## Article

## Source facts

Key Vault’s Linux extension 4.x separates the certificate chain into a .pem file and the private key into a .keyid file, replacing the combined-file layout of 3.0. Stable symbolic links point at the newest versions, and .luma metadata changes after those links are updated. Configured POSIX ACLs grant private-key read access; ACL enforcement is always enabled. Upgrading leaves previously downloaded files untouched. The documented platforms are Ubuntu 24.04, Azure Linux 3.0/4.0, and RHEL 9 on AMD64 or ARM64. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/key-vault-linux).

## Applicability

Review an actual 3.0 consumer before adopting the 4.x file contract. Identify whether it reads a combined file, a fixed versioned filename, or a symbolic link. Confirm the distribution against the supported list rather than assuming that every Linux guest can install this handler.

## DSE recommendation

Map the application’s chain path, private-key path, reload signal, and file-reading identity before upgrading the extension. Update the consumer to the separate files and plan how it will notice a completed renewal. Inspect retained legacy files deliberately; their continued presence should not be mistaken for proof that the application uses the new layout.

## Verification

In an approved test deployment, inspect the two stable links and the application account’s effective file access. Exercise a certificate renewal and compare the installed version with the certificate actually served by the application. Verify the intended reload behavior without exposing private-key contents in logs. Keep installation success separate from proof that the live process adopted the renewed certificate.

## Official references

[Microsoft Learn: Key Vault VM extension for Linux](https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/key-vault-linux). Source reviewed September 9, 2026.

## Primary reference

- Name: Azure Key Vault virtual machine extension for Linux - Azure Virtual Machines | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/virtual-machines/extensions/key-vault-linux
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Update Linux certificate consumers for the Key Vault extension's split-file format,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-331-update-linux-certificate-consumers-for-the-key-vault-extension-s-split-file-format/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.