Merge branch 'MicrosoftDocs:main' into FirmwareAnalysis

Author: eross-msft

.openpublishing.redirection.json

@@ -5375,51 +5375,6 @@
       "redirect_url": "/azure/role-based-access-control/resource-provider-operations",
       "redirect_document_id": false
     },
-    {
-      "source_path_from_root": "/articles/scheduler/get-started-portal.md",
-      "redirect_url": "/azure/scheduler/migrate-from-scheduler-to-logic-apps",
-      "redirect_document_id": false
-    },
-    {
-      "source_path_from_root": "/articles/scheduler/scheduler-advanced-complexity.md",
-      "redirect_url": "/azure/scheduler/migrate-from-scheduler-to-logic-apps",
-      "redirect_document_id": false
-    },
-    {
-      "source_path_from_root": "/articles/scheduler/scheduler-concepts-terms.md",
-      "redirect_url": "/azure/scheduler/migrate-from-scheduler-to-logic-apps",
-      "redirect_document_id": false
-    },
-    {
-      "source_path_from_root": "/articles/scheduler/scheduler-high-availability-reliability.md",
-      "redirect_url": "/azure/scheduler/migrate-from-scheduler-to-logic-apps",
-      "redirect_document_id": false
-    },
-    {
-      "source_path_from_root": "/articles/scheduler/scheduler-intro.md",
-      "redirect_url": "/azure/scheduler/migrate-from-scheduler-to-logic-apps",
-      "redirect_document_id": false
-    },
-    {
-      "source_path_from_root": "/articles/scheduler/scheduler-limits-defaults-errors.md",
-      "redirect_url": "/azure/scheduler/migrate-from-scheduler-to-logic-apps",
-      "redirect_document_id": false
-    },
-    {
-      "source_path_from_root": "/articles/scheduler/scheduler-outbound-authentication.md",
-      "redirect_url": "/azure/scheduler/migrate-from-scheduler-to-logic-apps",
-      "redirect_document_id": false
-    },
-    {
-      "source_path_from_root": "/articles/scheduler/scheduler-plans-billing.md",
-      "redirect_url": "/azure/scheduler/migrate-from-scheduler-to-logic-apps",
-      "redirect_document_id": false
-    },
-    {
-      "source_path_from_root": "/articles/scheduler/scheduler-powershell-reference.md",
-      "redirect_url": "/azure/scheduler/migrate-from-scheduler-to-logic-apps",
-      "redirect_document_id": false
-    },
     {
       "source_path_from_root": "/articles/sdks/index.yml",
       "redirect_url": "https://azure.microsoft.com/downloads/",

articles/app-service/industry-wide-certificate-changes.md

@@ -0,0 +1,150 @@
+---
+title: Industry-wide certificate changes impacting Azure App Service
+description: Describes industry-wide TLS certificate changes that affect Azure App Service Managed Certificates and App Service Certificates, including scope, timelines, and required actions.
+author: msangapu-msft
+ms.author: msangapu
+ms.date: 02/03/2026
+ms.topic: conceptual
+ms.service: azure-app-service
+---
+
+# Industry-wide certificate changes impacting Azure App Service
+
+Industry-wide requirements defined by browser programs and the CA/Browser Forum (CA/B Forum) are changing how public TLS certificates are issued and validated. To remain compliant with these requirements, Azure App Service applies the changes to App Service Managed Certificates (ASMC) and App Service Certificates (ASC).
+
+Most customers using certificates within Azure App Service do not need to take action. However, certain scenarios may require customer action to avoid service disruption or may change how certificates are managed over time. This article explains what is changing, when action is required, and what operational impacts to expect.
+
+
+## Scope
+
+This article applies to:
+- App Service Managed Certificates (ASMC)
+- App Service Certificates (ASC)
+
+## When action is required
+Action is required **only** in the following scenarios to avoid service disruption:
+
+- **Certificate pinning**  
+  Apps that pin certificates or certificate chains must review and remove pinning before the certificate chain migration.
+
+- **Mutual TLS (mTLS)**  
+  Apps that rely on these certificates for client authentication must transition to an alternative authentication mechanism.
+
+If neither of these scenarios applies, no immediate action is required.
+
+## Operational changes to be aware of
+
+Some scenarios do not require immediate action, but may require changes to how you manage certificates over time:
+
+- **Exporting App Service Certificates**  
+  If you export certificates for use outside Azure App Service, you may need to re-export and update them more frequently due to the shortened validity period.
+
+- **Domain ownership validation (ASC only)**  
+  Domain ownership validation may be required more frequently for certificate issuance, renewals, or rekeys.
+
+
+## Quick reference: What’s changing
+
+| Change area | Affected certificate type | Customer impact |
+|------------|--------------------------|-----------------|
+| Certificate validity period | ASC only | Shorter validity with overlapping issuance |
+| Domain validation reuse | ASC only | More frequent domain validation required |
+| Certificate chain | ASMC and ASC | Certificate pinning must be removed |
+| Client authentication EKU | ASMC and ASC | mTLS using these certs no longer supported |
+
+## Certificate validity period (ASC only)
+
+### What’s changing
+Starting March 2026, App Service Certificates are issued with a shorter validity period of **198 days** to remain compliant with industry requirements defined by the CA/Browser Forum, including the schedule introduced in 
+[CA/Browser Forum Ballot SC‑081v3](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/).
+
+### Impact on App Service Managed Certificates (ASMC)
+No change. ASMCs already comply with the new industry requirements.
+
+### Impact on App Service Certificates (ASC)
+To maintain one year of certificate coverage, Azure App Service automatically issues overlapping certificates at no additional cost.
+
+- If App Service Certificates are used only with Azure App Service, no action is required. The platform automatically syncs and updates certificates.
+- If certificates are exported and used outside Azure App Service, the certificates may need to be re-exported more frequently due to the shorter validity period.
+
+
+## Domain validation reuse (ASC only)
+
+### What’s changing
+Starting March 2026, domain ownership validation for App Service Certificates can be reused for up to **198 days** to remain compliant with industry requirements defined by the CA/Browser Forum.
+
+### Impact on App Service Managed Certificates (ASMC)
+No change. Domain ownership validation for ASMC is automated and requires no customer action.
+
+### Impact on App Service Certificates (ASC)
+- Domain validation completed before March 2026 cannot be reused. Certificate issuance starting March 2026 requires domain ownership validation.
+- During March 2026, domain ownership validation might be required again for each renewal and rekey.
+- After March 2026, domain ownership must be revalidated only if the domain was not validated within the past 198 days.
+- App Service Certificates do not automatically revalidate domains.
+
+If validation is required, certificate orders remain in a pending issuance state until validation is completed.
+
+> [!IMPORTANT]
+> Failure to complete domain validation can result in certificate issuance or renewal failure, potentially leading to certificate expiration and service disruption.
+
+## Client authentication EKU (ASMC and ASC)
+
+App Service Managed Certificates and App Service Certificates will stop supporting the client authentication extended key usage (EKU) as part of industry-driven changes to public TLS certificates.
+
+For background on this change across Azure services, see [Changes to the Managed TLS feature](/azure/security/fundamentals/managed-tls-changes).
+
+> [!NOTE]
+> Apps that rely on these certificates for mutual TLS (mTLS) must transition to an alternative authentication mechanism before the migration dates.
+
+
+## Certificate chain changes (ASMC and ASC)
+
+Both App Service Managed Certificates and App Service Certificates will migrate to a new certificate chain as part of industry-driven updates to TLS certificates, which includes changes to certificate authorities and intermediates.
+
+Apps that pin certificates or certificate chains must review and remove pinning before the migration dates to avoid service disruption.
+
+For background on the managed TLS certificate authority changes across Azure services, see [Changes to the Managed TLS feature](/azure/security/fundamentals/managed-tls-changes).
+
+> [!NOTE]
+> Certificate pinning is not recommended for App Service Managed Certificates (ASMC), because certificate issuance and rotation are controlled by the service.  
+> For App Service Certificates (ASC), pinning may also break due to certificate chain changes and should be reviewed carefully before the migration.
+
+## Timeline of key dates
+
+| Date | Change | ASMC | ASC |
+|-----|--------|------|-----|
+| Feb–Mar 2026 | New certificate chain | Migrates to new chain | — |
+| Starting March 2026 | Validity period + validation reuse | — | Shortened validity and validation reuse |
+| Mar–Apr 2026 (TBD) | New certificate chain + Client auth EKU | — | Migrates to new chain; EKU removed |
+| Mar–Apr 2026 (TBD) | Client auth EKU | EKU removed | — |
+
+
+## Frequently asked questions
+
+### Will I lose certificate coverage due to the shorter validity period?
+No. For App Service Certificates, Azure App Service automatically issues overlapping certificates to maintain continuous coverage for the full term you purchased.
+
+### Are these changes specific to DigiCert or GoDaddy?
+No. These are industry-wide changes driven by browser programs and the CA/Browser Forum, and they apply to public TLS certificates issued by all certificate authorities.
+
+### Do these changes affect certificates from other certificate authorities?
+Yes. These are industry-wide changes that apply to public TLS certificates regardless of the issuing certificate authority. For certificates not managed by Azure App Service, contact your certificate authority for guidance.
+
+### Do I need to take action now?
+If you do not pin certificates and do not use these certificates for mutual TLS (mTLS), no immediate action is required.
+
+### Why does my App Service Managed Certificate show an expiration date in April 2026 even though it was renewed recently?
+App Service Managed Certificates are issued with an approximately six-month validity period, which already complies with current industry requirements.
+
+The April 2026 expiration date is not related to certificate validity changes. It reflects a certificate chain transition that is occurring across the industry to maintain browser trust.
+
+Certificates issued from the existing certificate chain can only be issued until April 2026. To address this, Azure App Service is migrating App Service Managed Certificates to a new certificate chain and reissuing certificates from that chain.
+
+For customers using App Service Managed Certificates as intended, this process is fully automated and no service disruption is expected. As a best practice, App Service Managed Certificates should not be pinned, because both the certificate and its issuing chain are managed and rotated by the platform.
+
+
+## Related documentation
+
+- App Service Managed Certificates
+- App Service Certificates
+- Configure TLS/SSL bindings in Azure App Service

articles/app-service/toc.yml

@@ -352,6 +352,9 @@ items:
         - name: Configure TLS mutual authentication
           href: app-service-web-configure-tls-mutual-auth.md
           displayName: TLS
+        - name: Industry-wide certificate changes 
+          href: industry-wide-certificate-changes.md
+          displayName: 2026 certificate changes
 - name: Database and service connection
   items:
     - name: Connectivity scenarios overview

articles/application-gateway/ssl-overview.md

@@ -5,7 +5,7 @@ services: application-gateway
 author: mbender-ms
 ms.service: azure-application-gateway
 ms.topic: concept-article
-ms.date: 10/09/2025
+ms.date: 02/16/2026
 ms.author: mbender
 
 # Customer intent: "As a cloud architect, I want to configure end to end TLS on the application gateway, so that I can ensure secure communication and compliance for sensitive data transmitted between clients and backend servers."
@@ -125,10 +125,22 @@ The following tables outline the differences in SNI between the v1 and v2 SKU in
 | --- | --- | --- |
 | If the client specifies SNI header and all the multi-site listeners are enabled with "Require SNI" flag | Returns the appropriate certificate and if the site doesn't exist (according to the server_name), then the connection is reset. | Returns appropriate certificate if available, otherwise, returns the certificate of the first HTTPS listener according to the order specified by the request routing rules associated with the HTTPS listeners|
 | If the client doesn't specify a SNI header and if all the multi-site headers are enabled with "Require SNI" | Resets the connection | Returns the certificate of the first HTTPS listener according to the order specified by the request routing rules associated with the HTTPS listeners
-| If the client doesn't specify SNI header and if there's a basic listener configured with a certificate | Returns the certificate configured in the basic listener to the client (default or fallback certificate) | Returns the certificate configured in the basic listener |
+| If the client doesn't specify SNI header and if there's a basic listener configured with a certificate | Returns the certificate configured in the basic listener to the client (default or fallback certificate) | Returns the certificate of the HTTPS listener with the highest priority routing rule. The basic listener certificate is **not** used as a fallback. |
+
+> [!IMPORTANT]
+> **V2 SKU default certificate behavior:** When a client connects without an SNI header (for example, using an IP address), Application Gateway V2 does **not** fall back to a basic listener's certificate. Instead, it always returns the certificate from the HTTPS listener whose associated request routing rule has the **highest priority** (lowest priority number). This behavior differs from the V1 SKU, which returns the basic listener's certificate as a fallback.
+
+> [!TIP]
+> **Controlling the default certificate with an SNI hole:** To prevent Application Gateway V2 from exposing a production site certificate when clients connect by IP address without SNI, you can configure an "SNI hole":
+>
+> 1. Create a **multi-site HTTPS listener** with a dummy hostname that doesn't match any real site (for example, `sni-hole.invalid`).
+> 2. Upload a **self-signed certificate** to this listener.
+> 3. Create a **request routing rule** associated with this listener and assign it the **highest priority** (lowest priority number) among all your rules.
+>
+> With this configuration, any connection without a matching SNI header receives the self-signed certificate instead of a valid site certificate. This prevents IP-only connections from obtaining information about your hosted sites.
 
 > [!NOTE]
-> When the client does not specify an SNI header, it is recommended that the user add a basic listener and rule to present a default SSL/TLS certificate.
+> For the V1 SKU, when the client doesn't specify an SNI header, it's recommended that the user add a basic listener and rule to present a default SSL/TLS certificate.
 
 > [!TIP]
 > The SNI flag can be configured with PowerShell or by using an ARM template. For more information, see [RequireServerNameIndication](/powershell/module/az.network/set-azapplicationgatewayhttplistener#-requireservernameindication) and [Quickstart: Direct web traffic with Azure Application Gateway - ARM template](quick-create-template.md#review-the-template).
@@ -140,7 +152,7 @@ The following tables outline the differences in SNI between the v1 and v2 SKU in
 
 |Scenario | v1 | v2 |
 | --- | --- | --- |
-| When an FQDN or SNI is configured | Set as FQDN from the backend pool. As per [RFC 6066](https://tools.ietf.org/html/rfc6066), literal IPv4 and IPv6 addresses aren't permitted in SNI hostname. | The SNI value is set based on the [TLS validation type](configuration-http-settings.md?tabs=backendhttpsettings#backend-https-validation-settings) in the Backend Settings.<br><br> 1. **Complete validation** – The probes uses the SNI in the following order of precedence:<br> a) Custom Health Probe's hostname <br> b) Backend Setting's hostname (as per Overridden value or Pick from backend server) <br><br> 2.	**Configurable** <br> Use specific SNI: The probes use this fixed hostname for validation.<br> Skip SNI: No Subject Name validation.
+| When an FQDN or SNI is configured | Set as FQDN from the backend pool. As per [RFC 6066](https://tools.ietf.org/html/rfc6066), literal IPv4 and IPv6 addresses aren't permitted in SNI hostname. | The SNI value is set based on the [TLS validation type](configuration-http-settings.md?tabs=backendhttpsettings#backend-https-validation-settings) in the Backend Settings.<br><br> 1. **Complete validation** – The probe uses the SNI in the following order of precedence:<br> a) Custom Health Probe's hostname <br> b) Backend Setting's hostname (as per Overridden value or Pick from backend server) <br><br> 2.	**Configurable** <br> Use specific SNI: The probes use this fixed hostname for validation.<br> Skip SNI: No Subject Name validation.
 | When an FQDN or SNI is NOT configured (only IP address is available)  | SNI (server_name) won’t be set. <br> **Note:** In this case, the backend server should be able to return a default/fallback certificate and this should be allow-listed in HTTP settings under authentication certificate. If there’s no default/fallback certificate configured in the backend server and SNI is expected, the server might reset the connection and will lead to probe failures | If the Custom Probe or Backend Settings use an IP address in the hostname field, the SNI is not set, in accordance with [RFC 6066](https://tools.ietf.org/html/rfc6066). This includes cases where the default probe uses 127.0.0.1. |
 
 #### For live traffic

articles/azure-functions/durable/durable-functions-orchestrations.md

@@ -408,27 +408,37 @@ It isn't possible to pass multiple parameters to an activity function directly.
 
 # [C# (InProc)](#tab/csharp-inproc)
 
-In .NET, you can also use [ValueTuple](/dotnet/csharp/language-reference/builtin-types/value-tuples) objects to pass multiple parameters. The following sample uses [ValueTuple](/dotnet/csharp/language-reference/builtin-types/value-tuples) features added with [C# 7](/dotnet/csharp/whats-new/csharp-version-history#c-version-70):
+In .NET, you can use a class to pass multiple parameters:
 
 ```csharp
+public class CourseInfo
+{
+    public string Major { get; set; }
+    public int UniversityYear { get; set; }
+}
+
 [FunctionName("GetCourseRecommendations")]
 public static async Task<object> RunOrchestrator(
     [OrchestrationTrigger] IDurableOrchestrationContext context)
 {
-    string major = "ComputerScience";
     int universityYear = context.GetInput<int>();
+    CourseInfo courseInfo = new CourseInfo 
+    { 
+        Major = "ComputerScience", 
+        UniversityYear = universityYear 
+    };
 
     object courseRecommendations = await context.CallActivityAsync<object>(
         "CourseRecommendations",
-        (major, universityYear));
+        courseInfo);
     return courseRecommendations;
 }
 
 [FunctionName("CourseRecommendations")]
 public static async Task<object> Mapper([ActivityTrigger] IDurableActivityContext inputs)
 {
     // Parse the input for the student's major and year in university.
-    (string Major, int UniversityYear) studentInfo = inputs.GetInput<(string, int)>();
+    CourseInfo studentInfo = inputs.GetInput<CourseInfo>();
 
     // Retrieve and return course recommendations by major and university year.
     return new