Merge branch 'MicrosoftDocs:main' into geo-replication-pre-ga

Author: EldertGrootenboer

articles/application-gateway/mutual-authentication-troubleshooting.md

@@ -5,7 +5,7 @@ services: application-gateway
 author: mbender-ms
 ms.service: azure-application-gateway
 ms.topic: troubleshooting
-ms.date: 02/18/2022
+ms.date: 07/09/2025
 ms.author: mbender
 # Customer intent: As an application administrator, I want to troubleshoot mutual authentication issues on the Application Gateway, so that I can ensure secure communication and resolve errors efficiently.
 ---
@@ -16,17 +16,19 @@ Learn how to troubleshoot problems with mutual authentication when using Applica
 
 ## Overview 
 
-After configuring mutual authentication on an Application Gateway, there can be a number of errors that appear when trying to use mutual authentication. Some common causes for errors include:
+For mutual authentication on an Application Gateway, various errors can occur during client certificate validation after configuring. Common causes for these errors include:
 
-* Uploaded a certificate or certificate chain without a root CA certificate
-* Uploaded a certificate chain with multiple root CA certificates
-* Uploaded a certificate chain that only contained a leaf certificate without a CA certificate 
-* Validation errors due to issuer DN mismatch  
+* Upload a certificate or certificate chain without a root CA certificate
+* Upload a certificate chain with multiple root CA certificates
+* Upload a certificate chain that contains only a leaf certificate without a CA certificate 
+* Certificate validation errors due to issuer Distinguished Name (DN) mismatch  
+* Missing or incorrect Extended Key Usage (EKU) attributes
 
-We'll go through different scenarios that you might run into and how to troubleshoot those scenarios. We'll then address error codes and explain likely causes for certain error codes you might be seeing with mutual authentication. All client certificate authentication failures should result in an HTTP 400 error code. 
+This guide covers different scenarios you might encounter and provides troubleshooting steps for each. We also address specific error codes and explain their likely causes in mutual authentication scenarios. All client certificate authentication failures result in an HTTP 400 (Bad Request) status code being returned to the client. 
 
 ## Scenario troubleshooting - configuration problems
-There are a few scenarios that you might be facing when trying to configure mutual authentication. We'll walk through how to troubleshoot some of the most common pitfalls. 
+
+The following scenarios address common configuration issues that can occur when setting up mutual authentication. Each scenario includes the problem description and recommended solution. 
 
 ### Self-signed certificate
 
@@ -36,65 +38,81 @@ The client certificate you uploaded is a self-signed certificate and is resultin
 
 #### Solution 
 
-Double check that the self-signed certificate that you're using has the extension *BasicConstraintsOid* = "2.5.29.19" which indicates the subject can act as a CA. This will ensure that the certificate used is a CA certificate. For more information about how to generate self-signed client certificates, check out [trusted client certificates](./mutual-authentication-certificate-management.md).
+Verify that the self-signed certificate you're using includes the *BasicConstraintsOid* extension with value "2.5.29.19" and the CA flag set to TRUE. This extension indicates that the certificate subject can act as a Certificate Authority. 
+
+To check the certificate properties, you can use the following OpenSSL command:
+```bash
+openssl x509 -in certificate.pem -text -noout
+```
+
+Look for the "Basic Constraints" section in the output, which should show "CA:TRUE" for a valid CA certificate. For detailed guidance on generating self-signed client certificates, see [trusted client certificates](./mutual-authentication-certificate-management.md).
 
 ## Scenario troubleshooting - connectivity problems
 
-You might have been able to configure mutual authentication without any problems but you're running into problems when sending requests to your Application Gateway. We address some common problems and solutions in the following section. You can find the *sslClientVerify* property in the access logs of your Application Gateway. 
+You might be able to configure mutual authentication without any problems but you're running into problems when sending requests to your Application Gateway. We address some common problems and solutions in the following section. You can find the *sslClientVerify* property in the access logs of your Application Gateway. 
 
 ### SslClientVerify is NONE
 
 #### Problem 
 
-The property *sslClientVerify* is appearing as "NONE" in your access logs. 
+The *sslClientVerify* property appears as "NONE" in your access logs, indicating that no client certificate was presented during the TLS handshake. 
 
 #### Solution 
 
-This is seen when the client doesn't send a client certificate when sending a request to the Application Gateway. This could happen if the client sending the request to the Application Gateway isn't configured correctly to use client certificates. One way to verify that the client authentication setup on Application Gateway is working as expected is through the following OpenSSL command:
+This problem occurs when the client doesn't send a client certificate in the TLS handshake request to the Application Gateway. This problem can happen when:
+- The client application isn't configured to use client certificates
+- The client certificate isn't properly installed or accessible
+- The client doesn't trust the Application Gateway's server certificate
+
+To verify that client authentication is configured correctly on Application Gateway, use the following OpenSSL command:
 
 ```
 openssl s_client -connect <hostname:port> -cert <path-to-certificate> -key <client-private-key-file> 
 ```
 
-The `-cert` flag is the leaf certificate, the `-key` flag is the client private key file. 
+Where:
+- `-cert` specifies the path to the client certificate (leaf certificate)
+- `-key` specifies the path to the client private key file
+- `-verify_return_error` ensures the command fails if certificate verification fails
 
-For more information on how to use the OpenSSL `s_client` command, check out their [manual page](https://www.openssl.org/docs/manmaster/man1/openssl-s_client.html).
+For more information on using the OpenSSL `s_client` command, see the [OpenSSL manual page](https://www.openssl.org/docs/manmaster/man1/openssl-s_client.html).
 
 ### SslClientVerify is FAILED
 
 #### Problem
 
-The property *sslClientVerify* is appearing as "FAILED" in your access logs. 
+The *sslClientVerify* property appears as "FAILED" in your access logs, indicating that the client certificate validation failed during the TLS handshake. 
 
 #### Solution
 
-There are a number of potential causes for failures in the access logs. Below is a list of common causes for failure:
-* **Unable to get issuer certificate:** The issuer certificate of the client certificate couldn't be found. This normally means the trusted client CA certificate chain is not complete on the Application Gateway. Validate that the trusted client CA certificate chain uploaded on the Application Gateway is complete.  
-* **Unable to get local issuer certificate:** Similar to unable to get issuer certificate, the issuer certificate of the client certificate couldn't be found. This normally means the trusted client CA certificate chain is not complete on the Application Gateway. Validate that the trusted client CA certificate chain uploaded on the Application Gateway is complete.
-* **Unable to verify the first certificate:** Unable to verify the client certificate. This error occurs specifically when the client presents only the leaf certificate, whose issuer is not trusted. Validate that the trusted client CA certificate chain uploaded on the Application Gateway is complete.
-* **Unable to verify the client certificate issuer:** This error occurs when the configuration *VerifyClientCertIssuerDN* is set to true. This typically happens when the Issuer DN of the client certificate doesn't match the *ClientCertificateIssuerDN* extracted from the trusted client CA certificate chain uploaded by the customer. For more information about how Application Gateway extracts the *ClientCertificateIssuerDN*, check out [Application Gateway extracting issuer DN](./mutual-authentication-overview.md#verify-client-certificate-dn). As best practice, make sure you're uploading one certificate chain per file to Application Gateway. 
+There are many potential causes for failures in the access logs. Here's a list of common causes for failure:
+* **Unable to get issuer certificate:** The issuer certificate of the client certificate couldn't be found. This issue normally means the trusted client CA certificate chain isn't complete on the Application Gateway. Validate that the trusted client CA certificate chain uploaded on the Application Gateway is complete.  
+* **Unable to get local issuer certificate:** Similar to unable to get issuer certificate, the issuer certificate of the client certificate couldn't be found. This issue normally means the trusted client CA certificate chain isn't complete on the Application Gateway. Validate that the trusted client CA certificate chain uploaded on the Application Gateway is complete.
+* **Unable to verify the first certificate:** Unable to verify the client certificate. This error occurs specifically when the client presents only the leaf certificate, whose issuer isn't trusted. Validate that the trusted client CA certificate chain uploaded on the Application Gateway is complete.
+* **Unable to verify the client certificate issuer:** This error occurs when the configuration *VerifyClientCertIssuerDN* is set to true. This error typically happens when the Issuer DN of the client certificate doesn't match the *ClientCertificateIssuerDN* extracted from the trusted client CA certificate chain uploaded by the customer. For more information about how Application Gateway extracts the *ClientCertificateIssuerDN*, check out [Application Gateway extracting issuer DN](./mutual-authentication-overview.md#verify-client-certificate-dn). As best practice, make sure you're uploading one certificate chain per file to Application Gateway. 
 * **Unsupported certificate purpose:** Ensure the client certificate designates Extended Key Usage for Client Authentication ([1.3.6.1.5.5.7.3.2](https://oidref.com/1.3.6.1.5.5.7.3.2)). More details on definition of extended key usage and object identifier for client authentication can be found in [RFC 3280](https://www.rfc-editor.org/rfc/rfc3280) and [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280). 
 
 For more information on how to extract the entire trusted client CA certificate chain to upload to Application Gateway, see [how to extract trusted client CA certificate chains](./mutual-authentication-certificate-management.md).
 
 ## Error code troubleshooting
-If you're seeing any of the following error codes, we have a few recommended solutions to help resolve the problem you might be facing. 
+
+The following error codes appear when configuring mutual authentication. Each error includes the likely cause and recommended solution. 
 
 ### Error code: ApplicationGatewayTrustedClientCertificateMustSpecifyData
 
 #### Cause
 
-There is certificate data that is missing. The certificate uploaded could have been an empty file without any certificate data. 
+The uploaded certificate file is missing certificate data or contains an empty file without valid certificate content. 
 
 #### Solution
 
-Validate that the certificate file uploaded doesn't have any missing data. 
+Verify that the certificate file contains valid certificate data in the correct format (PEM). Use a text editor to confirm that the file contains certificate content between the `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----` delimiters. 
 
 ### Error code: ApplicationGatewayTrustedClientCertificateMustNotHavePrivateKey
 
 #### Cause
 
-There is a private key in the certificate chain. There shouldn't be a private key in the certificate chain. 
+There's a private key in the certificate chain. There shouldn't be a private key in the certificate chain. 
 
 #### Solution
 
@@ -104,15 +122,15 @@ Double check the certificate chain that was uploaded and remove the private key
 
 #### Cause
 
-There are two potential causes behind this error code.
-1. The parsing failed due to the chain not being presented in the right format. Application Gateway expects a certificate chain to be in PEM format and also expects individual certificate data to be delimited. 
-2. The parser didn't find anything to parse. The file uploaded could potentially only have had the delimiters but no certificate data. 
+There are two potential causes for this error:
+* **Parsing failure:** The certificate chain isn't in the correct format. Application Gateway expects certificate chains in PEM format with properly delimited individual certificates.
+* **Empty content:** The uploaded file contains only delimiters without actual certificate data between them. 
 
 #### Solution
 
-Depending on the cause of this error, there are two potential solutions. 
-* Validate that the certificate chain uploaded was in the right format (PEM) and that the certificate data was properly delimited. 
-* Check that the certificate file uploaded contained the certificate data in addition to the delimiters. 
+Based on the specific cause, apply one of the following solutions:
+*  **Format issue:** Ensure the certificate chain is in PEM format with each certificate properly delimited by `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----` markers. Each certificate should be on separate lines within these delimiters.
+* **Missing data:** Verify that the certificate file contains actual certificate data between the delimiters, not just empty delimiters. 
 
 ### Error code: ApplicationGatewayTrustedClientCertificateDoesNotContainAnyCACertificate
 
@@ -122,7 +140,14 @@ The certificate uploaded only contained a leaf certificate without a CA certific
 
 #### Solution 
 
-Double check the certificate chain that was uploaded contained more than just the leaf certificate. The *BasicConstraintsOid* = "2.5.29.19" extension should be present and indicate the subject can act as a CA.
+Ensure the certificate chain includes at least one CA certificate with the proper *BasicConstraintsOid* extension (OID: 2.5.29.19) where the CA flag is set to TRUE. This extension indicates that the certificate subject can act as a Certificate Authority. 
+
+To verify a certificate's CA status, use:
+```bash
+openssl x509 -in certificate.pem -text -noout | grep -A 2 "Basic Constraints"
+```
+
+The output should show "CA:TRUE" for valid CA certificates.
 
 ### Error code: ApplicationGatewayOnlyOneRootCAAllowedInTrustedClientCertificate
 

articles/application-gateway/tutorial-url-redirect-powershell.md

@@ -27,7 +27,7 @@ In this article, you learn how to:
 
 The following example shows site traffic coming from both ports 8080 and 8081 and being directed to the same backend pools:
 
-![URL routing and redirection architecture](./media/tutorial-url-redirect-powershell/scenario.png)
+:::image type="content" source="./media/tutorial-url-redirect-powershell/scenario.png" alt-text="Diagram of URL routing and redirection architecture." lightbox="./media/tutorial-url-redirect-powershell/scenario.png":::
 
 ## Prerequisites
 

articles/cost-management-billing/manage/link-partner-id-power-apps-accounts.md

@@ -2,12 +2,12 @@
 title: Link a partner ID to your Power Platform and Dynamics Customer Insights accounts with your Azure credentials 
 description: This article helps Microsoft partners use their Azure credentials to provide customers with services for Microsoft Power Apps, Power Automate, Power BI and Dynamics Customer Insights.
 author: kendayMS
-ms.reviewer: macyso
+ms.reviewer: presharm
 ms.service: cost-management-billing
 ms.subservice: billing
 ms.topic: conceptual
 ms.date: 05/21/2025
-ms.author: macyso
+ms.author: presharm
 ms.custom: devx-track-azurepowershell, devx-track-azurecli 
 ms.devlang: azurecli
 ---

articles/cost-management-billing/manage/link-partner-id.md

@@ -2,8 +2,8 @@
 title: Link a partner ID to your account that’s used to manage customers
 description: Track engagements with Azure customers by linking a partner ID to the user account that you use to manage the customer's resources.
 author: kendayMS
-ms.reviewer: macyso
-ms.author: macyso
+ms.reviewer: presharm
+ms.author: presharm
 ms.date: 05/21/2025
 ms.service: cost-management-billing
 ms.subservice: billing

articles/cost-management-billing/manage/programmatically-create-subscription-microsoft-customer-agreement-across-tenants.md

@@ -1,13 +1,13 @@
 ---
 title: Programmatically create MCA subscriptions across tenants
 description: Learn how to programmatically create an Azure MCA subscription across Microsoft Entra tenants, including necessary steps and considerations.
-author: kendayMS
+author: presharm
 ms.service: cost-management-billing
 ms.subservice: billing
 ms.topic: how-to
 ms.date: 05/29/2025
-ms.reviewer: macyso
-ms.author: macyso
+ms.reviewer: presharm
+ms.author: presharm
 ---
 
 # Programmatically create MCA subscriptions across Microsoft Entra tenants

articles/cost-management-billing/troubleshoot-billing/how-to-create-azure-support-request-ea.md

@@ -3,13 +3,13 @@ title: How to create an Azure support request for an Enterprise Agreement issue
 description: Enterprise Agreement customers who need assistance can use the Azure portal to find self-service solutions and to create and manage support requests.
 ms.topic: troubleshooting
 ms.date: 05/21/2025
-ms.author: macyso
+ms.author: presharm
 author: KennyDay
-ms.reviewer: macyso
+ms.reviewer: presharm
 ms.service: cost-management-billing
 ms.subservice: billing
 ms.custom:
-  - build-2025
+- build-2025
 ---
 
 # Create an Azure support request for an Enterprise Agreement issue