This blog contains information about *.azurewebsites.net TLS certificate changes for Web Apps, Functions, and Logic Apps (Standard). Customers should not be impacted by this change. The scope of services affected includes Web Apps, Functions, and Logic Apps (Standard); Logic Apps (Consumption) and resources hosted on an ASE are not impacted. This change is limited to public Azure cloud; government clouds are not affected.
Every Web Apps, Functions, and Logic Apps (Standard) has its own default hostname that goes by “<resource-name>.azurewebsites.net” where App Service secures it with a wildcard *.azurewebsites.net TLS certificate. The current intermediate Microsoft PKI Subordinate CA certificates were set to expire on June 27th, 2024. App Service used these intermediate certificates in the default TLS certificate *.azurewebsites.net. On March 13th, 2024, App Service renewed the TLS certificate and used a new set of Subordinate CAs while the root certificate remained the same. Due to the distributed asynchronous nature of the renewal process, there isn’t an exact date when the new TLS certificate will be visible to individual Web Apps, Functions, and Logic Apps (Standard).
Terminology and Concepts
- Certificate Authority: (CA) An entity that is responsible for the creation, issuance, revocation, and management of certificates. The term applies equally to both Roots CAs and Subordinate CAs.
- Root CA: The top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates.
- Root Certificate: The self‐signed certificate issued by the Root CA to identify itself and to facilitate verification of certificates issued to its Subordinate CAs.
- Subordinate CA: (Sub CA) A Certification Authority whose certificate is signed by the Root CA or another Subordinate CA.
We expect that this change will be a non-event and will not impact customers. However, you may be impacted if an application has incorrectly taken a hard dependency on the *.azurewebsites.net TLS certificate, for example by way of “certificate pinning”. Certificate pinning is a practice where an application only allows a specific list of acceptable Certificate Authorities (CAs), public keys, thumbprints, etc. Applications should never pin to the *.azurewebsites.net TLS certificate. Applications requiring certificate stability should use custom domains in conjunction with custom TLS certificates for those domains. You can refer to the recommended best practices section of this article for more information.
Recommended best practices
Certificate pinning of *.azurewebsites.net TLS certificates is not recommended because the *.azurewebsites.net TLS certificate could be rotated anytime given the nature of App Service as a Platform as a Service (PaaS). In the event that the service rotates the App Service default wildcard TLS certificate, certificate pinned applications will break and disrupt the connectivity for applications that are hardcoded to a specific set of certificate attributes. The periodicity with which the *.azurewebsites.net TLS certificate is rotated is also not guaranteed since the rotation frequency can change at any time.
If an application needs to rely on certificate pinning behavior, it is recommended to add a custom domain to a Web Apps, Functions, and Logic Apps (Standard) and provide a custom TLS certificate for the domain which can then be relied on for certificate pinning.
Note that applications which rely on certificate pinning should also not have a hard dependency on an App Service Managed Certificate. App Service Managed Certificates could be rotated anytime, leading to similar problems for applications that rely on stable certificate properties. It is best practice to provide a custom TLS certificate for applications that rely on certificate pinning.
Refer to our documentation for best practices for Azure App Service for more information.
