Azure App Service Certificate became unusable before displayed expiry after rekey/reissue — RCA and escalation requested

Question

Azure App Service Certificate became unusable before displayed expiry after rekey/reissue — RCA and escalation requested

Eddy Blatt 1

Details

This relates to a resolved production incident involving an Azure App Service Certificate used by an Azure Function App with an SNI custom-domain binding.

Because this is a public forum, I have intentionally omitted our subscription ID, tenant/resource-group names, exact resource names, domain names, certificate thumbprints/serial numbers and domain-validation tokens. I have timestamped Azure screenshots and the exact identifiers available and can provide these privately if this is escalated to a formal Azure Support case.

What happened

Earlier in the week we had begun the normal rekey/reissue process for an Azure App Service Certificate.

A newly issued certificate/version existed in Azure, but we had deliberately not completed the production certificate cutover yet. The existing certificate remained the certificate being used by the production Function App/custom-domain binding while we planned to complete the change during a lower-traffic maintenance window.

Azure showed the existing production certificate with an expiry date of 15 August 2026.

On 7 August 2026, approximately eight days before that displayed expiry date, production HTTPS clients unexpectedly began rejecting the certificate.

This forced us to perform the remaining certificate work as an emergency production change rather than during the planned maintenance window.

What we observed during recovery

During the emergency investigation/recovery:

We performed Sync on the Azure App Service Certificate.

Azure showed that a newer issued certificate/version existed in the Azure certificate/Key Vault lifecycle.

However, the Function App was still showing/using the previous certificate. Sync alone did not move the Function App custom-domain binding onto the newly issued certificate.

We therefore went to the Function App:

Certificates → Add certificate → Import App Service Certificate

and imported the newly issued App Service Certificate into the Function App.

A new Function App certificate entry then appeared with the new thumbprint and later expiry.

We went to:

Custom domains → Update binding

selected the newly imported certificate, retained SNI SSL, and updated the binding.

Immediately after that binding update, the production API recovered and HTTPS worked normally again.

We therefore know how we recovered the service. What we do not know is why the certificate that was still bound to production became unacceptable to clients before the expiry date Azure displayed.

Domain validation context

Our public DNS is managed by an external DNS/domain provider rather than Azure. Where Azure required domain-ownership verification during certificate issuance/rekey, an administrator with access to that DNS provider completed the requested validation.

We are not asserting that the DNS provider caused the TLS failure. Our understanding is that DNS/domain validation and the Azure-hosted TLS certificate/binding are separate concerns.

Please confirm whether that understanding is correct and whether any domain-validation/rekey state could cause an already-issued and already-bound production certificate to become unusable before its stated expiry.

Questions for Microsoft

1. Why did the previously bound certificate stop being accepted before its displayed expiry?

Could it have been revoked, deactivated, superseded, replaced, or otherwise made unusable as part of the App Service Certificate rekey/reissue lifecycle?

2. Can initiating Rekey/Reissue affect the currently bound production certificate before Sync or an explicit binding change is performed?

Our expectation was that the existing bound certificate would continue functioning until either:

we explicitly cut over to the newly issued certificate, or

the existing certificate reached its NotAfter/expiry date.

Is that expectation correct?

3. What exactly does Sync change?

In particular, please distinguish between:

the App Service Certificate resource;

the Key Vault certificate/secret version;

the certificate imported/available to the Function App; and

the certificate actually selected by an SNI custom-domain binding.

4. Should Sync have updated the Function App automatically?

In our case a newer certificate existed, but Sync did not result in the Function App using it.

The working recovery was:

Import App Service Certificate → verify new Function App certificate → explicitly update SNI binding

Is that the expected production procedure for this architecture, or should Sync normally have propagated the new certificate/binding automatically?

5. Is the old certificate guaranteed to remain usable between Rekey and cutover?

If not, what event can make it unusable before its displayed expiry, and how is a customer expected to know that this has happened or is about to happen?

6. Can Microsoft inspect the historical certificate lifecycle for 7 August 2026?

We need the authoritative Microsoft-side events/timestamps for the affected certificate, including where available:

issuance/reissue;

revocation status;

supersession/replacement;

Key Vault version changes;

App Service Certificate Sync events;

Function App certificate state; and

hostname/SNI binding changes.

We do not have access to enough historical platform-side information in the Azure portal to determine this ourselves.

7. Was there any Azure platform action or service incident that could have contributed?

The Azure portal has subsequently surfaced an App Service service/maintenance notice affecting our region. We can provide its tracking details privately. Please confirm whether any relevant platform event occurred at the time of this incident.

8. What monitoring should we configure?

We need an alert that detects that a certificate is no longer trusted/usable by real HTTPS clients, rather than relying solely on the expiry date displayed in Azure.

Production-safe procedure requested

Please also provide Microsoft's recommended sequence for future App Service Certificate rekeys for this architecture.

Specifically, we would like the authoritative order for:

Rekey → domain verification → certificate issuance → Sync → Function App certificate import/verification → SNI binding update → external HTTPS verification → retirement of old certificate

Please identify which of those steps Azure performs automatically and which require an explicit administrator action.

Request for escalation

This question concerns a historical production outage and the internal lifecycle state of an Azure-managed certificate. I do not believe the root cause can be established purely from configuration guidance or documentation.

If Priority Community Support / Microsoft Q&A does not have access to the Microsoft-side historical certificate lifecycle, revocation, synchronization and binding evidence required to determine the cause, please escalate this to a formal Azure Support case and provide the support case/ticket ID.

We have the exact Azure subscription/resource identifiers, certificate names and thumbprints, domain information, timestamped screenshots and incident records available to provide privately to the assigned Microsoft engineer.Title

Azure App Service Certificate became unusable before displayed expiry after rekey/reissue — RCA and escalation requested

Details

This relates to a resolved production incident involving an Azure App Service Certificate used by an Azure Function App with an SNI custom-domain binding.

Because this is a public forum, I have intentionally omitted our subscription ID, tenant/resource-group names, exact resource names, domain names, certificate thumbprints/serial numbers and domain-validation tokens. I have timestamped Azure screenshots and the exact identifiers available and can provide these privately if this is escalated to a formal Azure Support case.

What happened

Earlier in the week we had begun the normal rekey/reissue process for an Azure App Service Certificate.

A newly issued certificate/version existed in Azure, but we had deliberately not completed the production certificate cutover yet. The existing certificate remained the certificate being used by the production Function App/custom-domain binding while we planned to complete the change during a lower-traffic maintenance window.

Azure showed the existing production certificate with an expiry date of 15 August 2026.

On 7 August 2026, approximately eight days before that displayed expiry date, production HTTPS clients unexpectedly began rejecting the certificate.

This forced us to perform the remaining certificate work as an emergency production change rather than during the planned maintenance window.

What we observed during recovery

During the emergency investigation/recovery:

We performed Sync on the Azure App Service Certificate.

Azure showed that a newer issued certificate/version existed in the Azure certificate/Key Vault lifecycle.

However, the Function App was still showing/using the previous certificate. Sync alone did not move the Function App custom-domain binding onto the newly issued certificate.

We therefore went to the Function App:

Certificates → Add certificate → Import App Service Certificate

and imported the newly issued App Service Certificate into the Function App.

A new Function App certificate entry then appeared with the new thumbprint and later expiry.

We went to:

Custom domains → Update binding

selected the newly imported certificate, retained SNI SSL, and updated the binding.

Immediately after that binding update, the production API recovered and HTTPS worked normally again.

We therefore know how we recovered the service. What we do not know is why the certificate that was still bound to production became unacceptable to clients before the expiry date Azure displayed.

Domain validation context

Our public DNS is managed by an external DNS/domain provider rather than Azure. Where Azure required domain-ownership verification during certificate issuance/rekey, an administrator with access to that DNS provider completed the requested validation.

We are not asserting that the DNS provider caused the TLS failure. Our understanding is that DNS/domain validation and the Azure-hosted TLS certificate/binding are separate concerns.

Please confirm whether that understanding is correct and whether any domain-validation/rekey state could cause an already-issued and already-bound production certificate to become unusable before its stated expiry.

Questions for Microsoft

1. Why did the previously bound certificate stop being accepted before its displayed expiry?

Could it have been revoked, deactivated, superseded, replaced, or otherwise made unusable as part of the App Service Certificate rekey/reissue lifecycle?

2. Can initiating Rekey/Reissue affect the currently bound production certificate before Sync or an explicit binding change is performed?

Our expectation was that the existing bound certificate would continue functioning until either:

we explicitly cut over to the newly issued certificate, or

the existing certificate reached its NotAfter/expiry date.

Is that expectation correct?

3. What exactly does Sync change?

In particular, please distinguish between:

the App Service Certificate resource;

the Key Vault certificate/secret version;

the certificate imported/available to the Function App; and

the certificate actually selected by an SNI custom-domain binding.

4. Should Sync have updated the Function App automatically?

In our case a newer certificate existed, but Sync did not result in the Function App using it.

The working recovery was:

Import App Service Certificate → verify new Function App certificate → explicitly update SNI binding

Is that the expected production procedure for this architecture, or should Sync normally have propagated the new certificate/binding automatically?

5. Is the old certificate guaranteed to remain usable between Rekey and cutover?

If not, what event can make it unusable before its displayed expiry, and how is a customer expected to know that this has happened or is about to happen?

6. Can Microsoft inspect the historical certificate lifecycle for 7 August 2026?

We need the authoritative Microsoft-side events/timestamps for the affected certificate, including where available:

issuance/reissue;

revocation status;

supersession/replacement;

Key Vault version changes;

App Service Certificate Sync events;

Function App certificate state; and

hostname/SNI binding changes.

We do not have access to enough historical platform-side information in the Azure portal to determine this ourselves.

7. Was there any Azure platform action or service incident that could have contributed?

The Azure portal has subsequently surfaced an App Service service/maintenance notice affecting our region. We can provide its tracking details privately. Please confirm whether any relevant platform event occurred at the time of this incident.

8. What monitoring should we configure?

We need an alert that detects that a certificate is no longer trusted/usable by real HTTPS clients, rather than relying solely on the expiry date displayed in Azure.

Production-safe procedure requested

Please also provide Microsoft's recommended sequence for future App Service Certificate rekeys for this architecture.

Specifically, we would like the authoritative order for:

Rekey → domain verification → certificate issuance → Sync → Function App certificate import/verification → SNI binding update → external HTTPS verification → retirement of old certificate

Please identify which of those steps Azure performs automatically and which require an explicit administrator action.

Request for escalation

This question concerns a historical production outage and the internal lifecycle state of an Azure-managed certificate. I do not believe the root cause can be established purely from configuration guidance or documentation.

If Priority Community Support / Microsoft Q&A does not have access to the Microsoft-side historical certificate lifecycle, revocation, synchronization and binding evidence required to determine the cause, please escalate this to a formal Azure Support case and provide the support case/ticket ID.

We have the exact Azure subscription/resource identifiers, certificate names and thumbprints, domain information, timestamped screenshots and incident records available to provide privately to the assigned Microsoft engineer.

Ajay Rathod 260 Reputation points Microsoft External Staff Moderator

2026-08-13T06:43:36.0533333+00:00

Thanks for reaching out to Q&A.
We are looking into this, and we will reach out to you for any updates.
Eddy Blatt 1 Reputation point

2026-08-13T23:42:35.58+00:00
Thanks Ajay. I appreciate that you are looking into this.

I want to make one point very clear so this does not get treated as a generic certificate-renewal/configuration question.

The certificate involved was an Azure App Service Certificate issued and managed through Azure, serving our Azure App Service/Function App endpoint behind Azure Traffic Manager. Azure displayed an expiry date of 15 August 2026 — tomorrow. Production clients began rejecting the HTTPS connection on 7 August 2026, eight days before that displayed expiry.

The AI-generated response initially provided did not explain that event. We already know how to renew, Sync, import and bind certificates, and we successfully restored production by importing the newly issued App Service Certificate and explicitly updating the SNI binding.

What we need Microsoft to establish is why production HTTPS failed on 7 August while the certificate Azure showed as expiring on 15 August was still the certificate we expected production to be using.

In particular, we need Microsoft to determine:

which certificate was actually being presented by the App Service endpoint at the time of the failure;

whether the previously bound certificate was revoked, superseded, deactivated or otherwise affected by the rekey/reissue process;

whether its certificate chain or trust/revocation state changed;

whether the effective SNI binding changed or failed to update as expected; and

whether any other Azure platform event contributed to the outage.

Our customers experienced a genuine production outage as a result. Advice to renew earlier or improve monitoring may be useful operational guidance, but it is not a root-cause explanation for clients rejecting an Azure-issued certificate eight days before the expiry date displayed by Azure.

We have the exact subscription/resource IDs, certificate names, thumbprints, timestamps and screenshots available privately.

If determining the cause requires Microsoft-side historical lifecycle, binding, certificate or platform data that cannot be accessed through Q&A, please escalate this now to a formal Azure Support case under Priority Community Support and provide us with the case/ticket ID.
Eddy Blatt 1 Reputation point

2026-08-17T00:55:45.35+00:00

Hi Ajay, following up as it is now 17 August.

We have still not received a substantive technical response or a formal Azure Support case ID. This is a historical production outage requiring Microsoft-side certificate lifecycle/binding investigation, as explained above.

Could you please confirm whether this has now been escalated and provide the case/ticket ID? If it has not yet been escalated, please do so now.
Eddy Blatt 1 Reputation point

2026-08-17T05:20:49.0366667+00:00
Hi Ajay, an update for the public record.

Thank you for privately providing the Azure Portal link intended to allow us to submit the support case. I followed that link and completed the full classification process, including:

the affected App Service Certificate;

Connection issues with SSL or TLS;

the related production Function App; and

the corresponding SSL/TLS connection issue for that Function App.

Unfortunately, at the end of that process Azure again presented only “Prioritized support on Microsoft Q&A / Get support on Microsoft Q&A”. It did not provide an option to submit a formal Azure Support case or generate a case/ticket ID.

This is disappointing. We purchased the Developer Support plan specifically so Microsoft could investigate a real production outage involving business-critical Azure-hosted APIs. We have followed the required PCS process, waited for Microsoft’s response, requested escalation, and then followed the private escalation link supplied by Microsoft — yet we are still being routed back to the same Q&A process and still do not have a formal support case.

To reiterate, this is not a request for generic certificate-renewal guidance. Production HTTPS failed on 7 August 2026, while Azure showed the certificate then expected to be serving production as expiring on 15 August 2026. The planned Sync/certificate cutover had not yet been completed; completing that cutover became part of our emergency recovery.

We need Microsoft-side historical investigation to establish what actually happened.

Could you please now have the formal Azure Support case created internally and provide us with the case/ticket ID? The portal workflow you supplied has unfortunately only returned us to Q&A.
Eddy Blatt 1 Reputation point

2026-08-17T05:50:22.48+00:00
Thanks for the update and for confirming there appears to be an issue with the DFM case-creation URL.

I have now provided the requested subscription, resource, tenant and contact details to you privately so that the formal Azure Support case can be raised.

For the public record, this remains an RCA request concerning the 7 August 2026 production HTTPS/TLS outage affecting our business-critical Azure-hosted APIs.

The relevant environment involves an Azure Function App/App Service endpoint behind Azure Traffic Manager, together with an Azure App Service Certificate and its associated certificate/binding lifecycle.

Importantly, a certificate rekey/reissue had been initiated beforehand, but the planned production Sync/certificate cutover had not yet been deliberately completed when the outage occurred. Completing the certificate Sync/import/binding work became part of the emergency recovery process.

We are therefore not assuming the root cause. We need Microsoft to determine from its historical platform records:

which certificate was actually being presented by the production endpoint at the time of failure;

whether the previously bound certificate had been revoked, superseded or otherwise made unusable before its displayed expiry;

the effective TLS/SNI binding state at the time;

the certificate synchronization/lifecycle state; and

the relevant Traffic Manager endpoint/routing state.

Exact subscription IDs, Resource IDs, tenant information, certificate thumbprints, timestamps and screenshots will be supplied privately through the formal support case.

Please let us know once that case has actually been created and provide the Azure Support case/ticket ID.

Your answer

Ajay Rathod 260 Reputation points Microsoft External Staff Moderator

2026-08-13T06:43:36.0533333+00:00

Thanks for reaching out to Q&A.
We are looking into this, and we will reach out to you for any updates.
Eddy Blatt 1 Reputation point

2026-08-17T00:55:45.35+00:00

Hi Ajay, following up as it is now 17 August.

We have still not received a substantive technical response or a formal Azure Support case ID. This is a historical production outage requiring Microsoft-side certificate lifecycle/binding investigation, as explained above.

Could you please confirm whether this has now been escalated and provide the case/ticket ID? If it has not yet been escalated, please do so now.
Eddy Blatt 1 Reputation point

2026-08-17T05:20:49.0366667+00:00

Hi Ajay, an update for the public record.

Thank you for privately providing the Azure Portal link intended to allow us to submit the support case. I followed that link and completed the full classification process, including:

the affected App Service Certificate;

Connection issues with SSL or TLS;

the related production Function App; and

the corresponding SSL/TLS connection issue for that Function App.

Unfortunately, at the end of that process Azure again presented only “Prioritized support on Microsoft Q&A / Get support on Microsoft Q&A”. It did not provide an option to submit a formal Azure Support case or generate a case/ticket ID.

This is disappointing. We purchased the Developer Support plan specifically so Microsoft could investigate a real production outage involving business-critical Azure-hosted APIs. We have followed the required PCS process, waited for Microsoft’s response, requested escalation, and then followed the private escalation link supplied by Microsoft — yet we are still being routed back to the same Q&A process and still do not have a formal support case.

To reiterate, this is not a request for generic certificate-renewal guidance. Production HTTPS failed on 7 August 2026, while Azure showed the certificate then expected to be serving production as expiring on 15 August 2026. The planned Sync/certificate cutover had not yet been completed; completing that cutover became part of our emergency recovery.

We need Microsoft-side historical investigation to establish what actually happened.

Could you please now have the formal Azure Support case created internally and provide us with the case/ticket ID? The portal workflow you supplied has unfortunately only returned us to Q&A.
Eddy Blatt 1 Reputation point

2026-08-17T05:50:22.48+00:00

Thanks for the update and for confirming there appears to be an issue with the DFM case-creation URL.

I have now provided the requested subscription, resource, tenant and contact details to you privately so that the formal Azure Support case can be raised.

For the public record, this remains an RCA request concerning the 7 August 2026 production HTTPS/TLS outage affecting our business-critical Azure-hosted APIs.

The relevant environment involves an Azure Function App/App Service endpoint behind Azure Traffic Manager, together with an Azure App Service Certificate and its associated certificate/binding lifecycle.

Importantly, a certificate rekey/reissue had been initiated beforehand, but the planned production Sync/certificate cutover had not yet been deliberately completed when the outage occurred. Completing the certificate Sync/import/binding work became part of the emergency recovery process.

We are therefore not assuming the root cause. We need Microsoft to determine from its historical platform records:

which certificate was actually being presented by the production endpoint at the time of failure;

whether the previously bound certificate had been revoked, superseded or otherwise made unusable before its displayed expiry;

the effective TLS/SNI binding state at the time;

the certificate synchronization/lifecycle state; and

the relevant Traffic Manager endpoint/routing state.

Exact subscription IDs, Resource IDs, tenant information, certificate thumbprints, timestamps and screenshots will be supplied privately through the formal support case.

Please let us know once that case has actually been created and provide the Azure Support case/ticket ID.