Certificate renewal changes Subject CN / SAN to a different managed hostname

[janegilring]

Describe the bug

We are using keyvault-acmebot for automated certificate management with Azure Key Vault and Let’s Encrypt.

A certificate originally created and renewed multiple times for:

medlemsvalgt.coopcloud.no

was unexpectedly renewed with a different Subject CN and SAN:

medlemsvalgt-kompetanse.coopcloud.no

No intentional configuration change was made to request this hostname during renewal.

Observed behavior

Original certificate (working as expected)

• Certificate name (Key Vault): medlemsvalgt-coopcloud-no
• Subject CN: medlemsvalgt.coopcloud.no
• SAN: medlemsvalgt.coopcloud.no
• Renewed successfully several times over multiple months

Renewed certificate (unexpected change)

• Certificate name (Key Vault): medlemsvalgt-coopcloud-no (unchanged)
• Subject CN: medlemsvalgt-kompetanse.coopcloud.no
• SAN: medlemsvalgt-kompetanse.coopcloud.no

This resulted in two managed certificates effectively pointing to the same DNS name, while the original hostname (medlemsvalgt.coopcloud.no) was no longer present on the renewed certificate.

Important additional context

We already have another managed certificate that has existed for the same amount of time as the original one:

Certificate name	DNS name
medlemsvalgt-kompetanse-coopcloud-no	medlemsvalgt-kompetanse.coopcloud.no

Both certificates have co‑existed without issues for months.

However, during the latest renewal cycle, the certificate named:

medlemsvalgt-coopcloud-no

was renewed using the DNS name of the other certificate instead of its original DNS name.

This suggests that hostname selection during renewal may be influenced by the presence of multiple managed certificates or overlapping hostname bindings.

Expected behavior

• Renewal of medlemsvalgt-coopcloud-no should retain:
  • Subject CN: medlemsvalgt.coopcloud.no
  • SAN: medlemsvalgt.coopcloud.no
• The existence of another managed certificate for a different hostname should not affect renewal behavior.
• Each managed certificate should remain isolated to its originally configured DNS name.

Questions

1. How does keyvault-acmebot determine the Subject CN / SAN during renewal?

   • Is it derived dynamically from current App Service / Function App hostname bindings?
   • Is it re‑evaluated at renewal time rather than persisted from initial issuance?

2. How does acmebot behave when multiple managed certificates exist with related or overlapping hostnames?

   • Is there any hostname de‑duplication or sorting logic?
   • Could alphabetical or binding order influence which hostname is selected?

3. Does the Key Vault certificate name play any role, or is hostname selection entirely runtime‑based?

4. Are there safeguards to ensure a 1:1 relationship between a managed certificate and its originally requested DNS name?

Troubleshooting / diagnostics guidance

Could you share recommended ways to troubleshoot this scenario?

Specifically:

• Are there specific log messages that indicate:

  • Which hostname was selected for renewal?
  • Whether other managed certificates or hostnames were considered?

• Are there any sample KQL queries for Application Insights / Log Analytics that are useful when diagnosing renewal issues?

Example starting points we’ve tried / are looking for confirmation on:

traces
| where message contains "acme"
| order by timestamp desc

traces
| where message contains "certificate" or message contains "hostname"
| project timestamp, severityLevel, message, customDimensions
| order by timestamp desc

Environment (high level)

• keyvault-acmebot version: 4.1.8
• Hosting: Azure App Service / Function App
• Certificate authority: Let’s Encrypt
• Storage: Azure Key Vault
• Application Insights: Enabled

Happy to provide additional logs, timestamps, or a minimal repro if helpful. Thanks in advance for any guidance—this looks like it may be an edge case around renewal and multiple managed certificates.

Environment (please complete the following information):

• Certificate Type: [e.g. Zone Apex, Sub-domain, Wildcard]
• Certificate Deploy Target: [e.g. App Service]

[JohnLBevan]

RE How does keyvault-acmebot determine the Subject CN / SAN during renewal? the information comes from Key Vault.

• Open the Azure Portal in your web browser
• Navigate to the key vault associated with AcmeBot
• Click Objects > Certificates
• Find and click on the certificate in question (note: this view is paged; if your cert doesn't show, click load more at the bottom of the table).
• Click Issuance Policy
• You'll see the subject here; though that's not that important. Click the DNS Names hyperlink to see the domains which this cert includes in its SAN list:
• If you change this list, click OK on the DNS names list, then click Save on the issuance policy to persist your changes.

Note: Only versions of the cert issued after the issuance policy is updated will have the updated list; so if you want to change things, after changing the list here go to the AcmeBot dashboard, find your cert, and hit Renew to get a fresh version based on the updated policy.

If you can check the issuance policy of the cert that's at fault that may give a clue as to wether this issue's down to some bug in AcmeBot or if it's a problem on the KeyVault side (be that an MS bug or simple config issue).
Sadly I don't think changes to the issuance policy show in Azure's activity log; so don't think there's an easy way to spot if someone/something amended this (deliberately or otherwise). You can click through older versions of the certificate and look at the Subject and Subject Alternative Name value of each version to see if they changed / get a window of ~60 days (assuming auto-renewal) in which the change occurred.

[shibayan]

As @JohnLBevan mentioned, Acmebot relies heavily on the Key Vault Issuance Policy, so verifying the Subject and SANs (DNS names) in the Issuance Policy is the quickest way to resolve this. While older versions might not have included the Subject, potentially causing this issue, you should primarily check the current Issuance Policy.