Blog Post

Apps on Azure Blog
8 MIN READ

SSL/TLS certificates and end-to-end encryption for Azure Functions Flex Consumption

nzthiago's avatar
nzthiago
Icon for Microsoft rankMicrosoft
Sep 14, 2026

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 boundaryCapability
Client to Azure Functions front endHTTPS and a certificate bound to the hostname
Azure platform front end to function workerEnd-to-end TLS encryption
Function code to a downstream serviceA private or public certificate made accessible to app code
Client identity presented to the function appClient-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 typeMaximum per appTypical uses
Private certificate (.pfx)3Custom-domain TLS bindings, outbound client authentication, signing, or decryption
Public certificate (.cer)3Trusting 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:

CertificateRuntime 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:

Published Sep 14, 2026
Version 1.0
No CommentsBe the first to comment