Secure custom domains, enable certificate-based application scenarios, and encrypt traffic all the way from the client to the function worker while keeping the scale and pay-as-you-go benefits of serverless.
Last week we announced the general availability of TLS/SSL certificate support and end-to-end TLS encryption for Azure Functions Flex Consumption.
Flex Consumption is the recommended serverless hosting plan for Azure Functions. It combines event-driven scale-to-zero and execution-based billing with fast scale-out, configurable instance memory, always-ready instances, and virtual network integration. With this release, customers can now apply a more complete transport-security model to HTTP-based serverless applications without moving to dedicated compute.
The new capabilities include:
- Site-scoped certificates, with up to three private certificates and three public certificates for each function app.
- Multiple certificate sources, including direct upload, Azure Key Vault, App Service Certificates, and free App Service Managed Certificates for supported custom domains.
- Per-certificate access from application code, replacing the broad WEBSITE_LOAD_CERTIFICATES model in Flex Consumption.
- End-to-end TLS encryption between the Azure platform front ends and the workers that run your functions.
Together, these features support common enterprise scenarios such as custom HTTPS endpoints, outbound client-certificate authentication, mutual TLS (mTLS), certificate-based cryptographic operations, and stricter encryption-in-transit requirements.
What end-to-end TLS means for a function app
It helps to separate the different places where TLS and certificates participate in an application request.
First, a client connects to your function app over HTTPS. For the default *.azurewebsites.net hostname, Azure provides and manages the certificate automatically. For a custom hostname such as api.contoso.com, you map the domain to the function app and bind an appropriate server certificate.
Second, Azure Functions receives the request at an Azure platform front end and routes it to a worker that runs your code. HTTPS has always protected the client-to-front-end connection. When end-to-end TLS is enabled, the front-end-to-worker connection is also encrypted. This removes the unencrypted internal hop that otherwise exists after TLS termination at the front end.
Third, your function code might call another service that requires a certificate. For example, a partner API that uses mTLS. A site-scoped private certificate can be exposed to the function runtime and loaded from the Linux file system for that outbound connection.
These controls are complementary:
| Traffic or trust boundary | Capability |
|---|---|
| Client to Azure Functions front end | HTTPS and a certificate bound to the hostname |
| Azure platform front end to function worker | End-to-end TLS encryption |
| Function code to a downstream service | A private or public certificate made accessible to app code |
| Client identity presented to the function app | Client-certificate authentication, with validation performed by application code |
End-to-end TLS does not replace a custom-domain certificate, and a certificate uploaded for use by code does not automatically configure mTLS. Each control protects a different boundary.
A certificate model designed for Flex Consumption
Traditional App Service certificate resources are scoped to a webspace, a deployment unit associated with an App Service plan's resource group, region, and operating system. Apps in the same webspace can share access to those certificates.
Flex Consumption apps don't share the same plan, so we have introduced a new site-scoped model. The certificate is a child resource of one function app and isn't shared with other apps. This tighter boundary makes certificate ownership easier to reason about, reduces unintended sharing, and aligns well with function apps that are deployed and governed independently like Flex Consumption.
Each Flex Consumption function app supports:
| Certificate type | Maximum per app | Typical uses |
|---|---|---|
| Private certificate (.pfx) | 3 | Custom-domain TLS bindings, outbound client authentication, signing, or decryption |
| Public certificate (.cer) | 3 | Trusting or validating remote resources from application code |
The three-certificate limit includes App Service Managed Certificates, App Service Certificates, Key Vault imports, and directly uploaded PFX files. Plan certificate usage before assigning a separate certificate to every hostname. A certificate with appropriate subject alternative names can be useful when one certificate must cover multiple hostnames.
Choose the right certificate source
Flex Consumption supports several certificate-management approaches:
App Service Managed Certificate. This is the simplest choice for a supported public custom domain. The domain-validated certificate is free, automatically issued, bound, and renewed by App Service. Managed certificates aren't exportable and don't support wildcard domains, private DNS, or use as an outbound client certificate. Avoid certificate pinning because the issuer, public key, and private key can change during renewal.
App Service Certificate. This paid option provides Azure-managed lifecycle capabilities with support for scenarios such as wildcard domains and export.
Azure Key Vault import. This is generally the preferred option when an organization centrally governs certificate issuance, access, and rotation. Use a managed identity and grant the Key Vault Certificate User role. When the certificate is renewed in Key Vault, the platform synchronizes the new version to the function app within 24 hours. If the vault blocks public access, enable the trusted Microsoft services bypass so the Azure Functions platform can retrieve the certificate.
Direct private certificate upload. Upload a password-protected PFX that includes the complete certificate chain, including intermediate and root certificates. For a custom-domain binding, the certificate must include the server-authentication extended key usage and be signed by a trusted certificate authority. Elliptic Curve Cryptography certificates are supported when uploaded as PFX.
Direct public certificate upload. Upload a CER when function code needs a public certificate. Public certificates aren't used to secure custom domains.
Configure the security foundation with infrastructure as code
The following Bicep excerpt shows the relevant settings on the function app. Add these properties to a complete Flex Consumption deployment that also defines the FC1 plan, deployment storage, runtime, identity, and monitoring resources.
resource functionApp 'Microsoft.Web/sites@2024-11-01' =
{
name: functionAppName
location: location
kind: 'functionapp,linux'
identity: { type: 'SystemAssigned' }
properties: {
serverFarmId: serverFarmResourceId
httpsOnly: true
siteScopedCertificatesEnabled: true
endToEndEncryptionEnabled: true
siteConfig:
{
minTlsVersion: '1.2'
}
functionAppConfig: { // Add the deployment, runtime, and scale configuration for your app. }
}
}
The settings have distinct purposes:
- httpsOnly redirects HTTP requests to HTTPS.
- siteConfig.minTlsVersion defines the minimum TLS version accepted for inbound connections.
- siteScopedCertificatesEnabled enables per-app certificate resources.
- endToEndEncryptionEnabled encrypts front-end-to-worker traffic.
You can also create certificate child resources with Microsoft.Web/sites/certificates@2024-11-01, including importing a certificate by specifying its Key Vault resource ID and secret name. Use secure deployment parameters for any certificate password or PFX content; never store private key material or passwords in source control.
Azure CLI doesn't currently provide dedicated commands to manage Flex Consumption site-scoped certificates. Use the Azure portal or ARM/Bicep for certificate operations.
For more on using Bicep and ARM to configure site-scoped certificates in Flex Consumption see Automate resource deployment for your function app in Azure Functions.
Add and use a certificate
After creating the app with site-scoped certificates enabled, choose the workflow that matches your scenario.
Secure a custom domain with a managed certificate
In the Azure portal, open the Flex Consumption function app. Under Settings, select Custom domains, and then select Add custom domain and configure the certificates. For customer-managed certificates, add or import the private certificate under Settings > Certificates, and then bind it to the custom domain. A domain showing as Secured confirms that a binding exists, but clients can still reject an expired, self-signed, name-mismatched, or incomplete certificate chain. Test the endpoint from representative client environments.
Make a certificate available to function code
Adding a certificate to the app does not automatically expose it to code. In Settings > Certificates, open the menu for the required certificate and select Make accessible to app code.
This per-certificate control replaces WEBSITE_LOAD_CERTIFICATES in Flex Consumption. That app setting remains valid for other supported Functions and App Service hosting plans, but it isn't used by Flex Consumption. The per-certificate model applies least privilege more naturally: expose only the certificates that the workload must read.
Flex Consumption runs on Linux, so accessible certificates are files rather than entries in a Windows certificate store:
| Certificate | Runtime location |
|---|---|
| Private | /var/ssl/private/<thumbprint>.p12 |
| Public | /var/ssl/certs/<thumbprint>.der |
Load the file by thumbprint using the certificate APIs for your language. Don't assume a Windows certificate store is available, and don't package private keys with the function code.
For Key Vault imports, the platform places a renewed certificate version on the function instances after synchronization. If your application hard-codes a thumbprint, account for the fact that renewal produces a new thumbprint. Prefer a configuration or discovery pattern that lets you rotate without a code release.
Enable mutual TLS without confusing transport and identity
For inbound mTLS, configure the function app to request a client certificate by using the appropriate client-certificate mode: Required, Optional, or Optional Interactive User.
Azure terminates the client TLS connection at the platform front end and forwards the presented certificate to the application in the X-ARR-ClientCert header. The platform forwards the certificate; your function code remains responsible for validating it. Validation should include the trusted issuer and chain, validity period, intended usage, revocation policy where applicable, and the application's authorization rules. Do not trust the presence of the header alone.
If you use exclusion paths or Optional Interactive User mode, review the TLS renegotiation behavior carefully. TLS 1.3 and HTTP/2 don't support renegotiation, and requests with bodies larger than 100 KB can fail in configurations that require renegotiation. Prefer a mode and route design that avoids renegotiation when possible.
For outbound mTLS, make the private certificate accessible to app code, load it from /var/ssl/private, and attach it to the TLS client used to call the downstream service. This is separate from enabling inbound client certificates.
Operational guidance for production
Treat certificates as rotating dependencies rather than static configuration:
- Inventory certificate purpose, owner, source, expiration, bound hostnames, and whether code access is enabled.
- Use managed identity and Key Vault for centrally governed certificates.
- Alert before expiration for directly uploaded certificates and rehearse renewal.
- Monitor custom-domain DNS because managed certificate issuance and renewal depend on successful domain validation.
- Avoid certificate or issuer pinning when using App Service Managed Certificates.
- Test certificate rotation on all scaled instances, not only one warm worker.
- Keep HTTPS-only enabled and require TLS 1.2 or later unless a documented compatibility requirement prevents it.
- Use Azure Policy and deployment validation to keep transport-security settings consistent across environments.
When migrating from the legacy Consumption plan, remember that WEBSITE_LOAD_CERTIFICATES isn't used in Flex Consumption. Re-add the certificates to the new app, explicitly grant code access where required, and update code that expects the Windows certificate store to load files from the Linux paths instead.
Get started
The general availability of site-scoped certificates and end-to-end TLS gives teams a stronger security foundation for serverless APIs and event-driven applications on Flex Consumption. You can now keep certificate ownership at the function-app boundary, automate certificate lifecycle through Azure Key Vault or App Service, and encrypt request traffic through the worker that executes your code, all while retaining dynamic scale and consumption-based billing.
Use the following resources to begin:
- Azure update: TLS/SSL certificate and end-to-end TLS encryption support for Azure Functions Flex Consumption
- Create and manage function apps in a Flex Consumption plan
- Azure Functions scale and hosting options: certificate support
- Automate Azure Functions resource deployment
- TLS in Azure App Service
- Configure TLS mutual authentication
- Flex Consumption site-scoped certificates sample