觀點 · 資訊分享
Azure Functions Flex Consumption 能裝自己的憑證了：自訂網域、mTLS 正式可用，但舊 App 要重建
Azure Functions 的 Flex Consumption 方案正式支援 TLS／SSL 憑證：每個函式應用程式可放 3 張私鑰憑證與 3 張公開憑證，也能用免費代管憑證或從 Key Vault 匯入。平台內部的端對端加密同步正式上線，不過功能上線前建立的 App 沒有遷移路徑。
- 發布
- 2026-09-11
- 篇幅
- 約 4 分鐘 · 1,817 字
- 結構
- 7 節 + 3 題常見問題
- 標籤
一句話看懂：Azure Functions 的 Flex Consumption 方案正式支援自己的 TLS／SSL 憑證，自訂網域、用戶端憑證驗證、mTLS 都能做，但功能上線前建立的 App 要重建才能用。
先用白話講：函式為什麼需要「憑證」？
憑證就像網站的身分證。瀏覽器看到網址列的小鎖頭，代表這個網站拿得出可信的身分證，傳輸過程也有加密。
Azure Functions 預設的 *.azurewebsites.net 網址，平台已經幫你準備好身分證。但如果你想用自己的網域（例如 api.example.com），或要去呼叫一個「你也得出示身分證才讓你連」的外部 API，就得自己把憑證放上去。後者叫用戶端憑證驗證，雙方互相出示身分證的做法叫 mTLS。
這次更新，就是讓 Flex Consumption 方案正式能放這些身分證。
發生什麼事
Microsoft 在 2026 年 9 月 10 日宣布兩項功能正式上線（GA）：
- 每個 App 自己的憑證（site-scoped certificates）：憑證只屬於單一函式應用程式，不再跟同一環境的其他 App 共用。每個 App 最多 3 張私鑰憑證（.pfx）與 3 張公開憑證（.cer）
- 三種來源：自己上傳、從 Azure Key Vault 匯入，或使用免費的 App Service 代管憑證
- 端對端 TLS 加密：連「平台前端」到「實際執行函式的工作節點」這一段內部傳輸也加密
導入前要知道的限制
| 限制 | 說明 |
|---|---|
| 舊 App | 功能上線前建立的 App 目前沒有遷移路徑，要用得新建 App |
| 管理工具 | Azure CLI 還不能管理這類憑證，先用入口網站或 ARM／Bicep |
| 私鑰憑證格式 | 要匯出成有密碼保護的 PFX，並包含完整憑證鏈；ECC 憑證可用 |
| 讀取方式 | 跑在 Linux，程式要從檔案路徑讀，不能用 Windows 憑證存放區 |
給開發者的技術細節
開啟端對端加密，在 ARM 或 Bicep 範本把網站屬性設為：
{
"properties": {
"endToEndEncryptionEnabled": true
}
}
讓程式讀到憑證：
- 在入口網站的「憑證」頁，對憑證選「可供應用程式碼存取」，平台才會把它放進每個執行個體
- 檔案以憑證指紋命名，公開憑證在
/var/ssl/certs，私鑰憑證在/var/ssl/private - .NET 程式若原本用
X509Store從 Windows 憑證存放區找憑證，要改成從上述路徑載入檔案
換證方式：
- 免費代管憑證由平台自動續約；第一次簽發最久可能要 10 分鐘
- 從 Key Vault 匯入的憑證，在 Key Vault 更新後 24 小時內自動同步到所有執行個體
- 自己上傳的憑證要重新上傳；程式若用指紋找憑證，記得一併更新設定
我的看法
做系統整合時，常會遇到對方要求「連線要出示用戶端憑證」，例如部分金流或企業內部 API。這次正式支援後，依用量計費的小型專案也能直接處理這類需求，不必為了憑證另外挑方案。不過兩個坑要先知道：舊 App 不能直接開，得新建一個再搬過去；.NET 程式若是從 Windows 憑證存放區讀憑證，要改成讀檔案。建議把憑證放 Key Vault，換證時就不用手動處理每個 App。
名詞小辭典
- TLS／SSL：網路傳輸的加密協定，網址列的小鎖頭就是靠它。
- mTLS（雙向 TLS）：連線雙方都要出示憑證，互相確認身分後才開始傳資料。
- Azure Key Vault：Azure 存放金鑰、密碼與憑證的保管箱服務。
- ARM／Bicep：用檔案描述 Azure 資源設定的工具，可以重複部署同一套環境。