[PACE 137872, 142516] Document CVE coverage and Key Vault CSI limitation

- PACE 137872: Added comprehensive CVE protection coverage documentation in application-gateway-crs-rulegroups-rules.md
- PACE 142516: Document AGfC certificate storage requirements
  - Added IMPORTANT note in migrate-from-agic-to-agc.md
  - Added Prerequisites note in how-to-ssl-offloading-gateway-api.md
  - Added Prerequisites note in how-to-ssl-offloading-ingress-api.md
- Fixed markdown table formatting errors in ssl-overview.md
- Fixed markdown table formatting in application-gateway-crs-rulegroups-rules.md

Author: riturajc

articles/application-gateway/for-containers/how-to-ssl-offloading-gateway-api.md

@@ -25,6 +25,9 @@ Application Gateway for Containers enables SSL [offloading](/azure/architecture/
 
 ## Prerequisites
 
+> [!NOTE]
+> Certificates for Application Gateway for Containers must be stored as Kubernetes secrets. Azure Key Vault integration via the [Secrets Store CSI driver](/azure/aks/csi-secrets-store-driver) is not supported because Application Gateway for Containers requires certificates to be local to the cluster and cannot mount them from external volumes. For automated certificate management, consider using [cert-manager with Let's Encrypt](how-to-cert-manager-lets-encrypt-gateway-api.md).
+
 1. If following the BYO deployment strategy, ensure that you set up your Application Gateway for Containers resources and ALB Controller ([Add-on](quickstart-deploy-application-gateway-for-containers-alb-controller-addon.md) or [Helm](quickstart-deploy-application-gateway-for-containers-alb-controller-helm.md))
 2. If following the ALB managed deployment strategy, ensure that you provision your ALB Controller ([Add-on](quickstart-deploy-application-gateway-for-containers-alb-controller-addon.md) or [Helm](quickstart-deploy-application-gateway-for-containers-alb-controller-helm.md)) and the Application Gateway for Containers resources via the  [ApplicationLoadBalancer custom resource](quickstart-create-application-gateway-for-containers-managed-by-alb-controller.md).
 3. Deploy sample HTTPS application

articles/application-gateway/for-containers/how-to-ssl-offloading-ingress-api.md

@@ -22,6 +22,9 @@ Application Gateway for Containers enables SSL [offloading](/azure/architecture/
 
 ## Prerequisites
 
+> [!NOTE]
+> Certificates for Application Gateway for Containers must be stored as Kubernetes secrets. Azure Key Vault integration via the [Secrets Store CSI driver](/azure/aks/csi-secrets-store-driver) is not supported because Application Gateway for Containers requires certificates to be local to the cluster and cannot mount them from external volumes. For automated certificate management, consider using [cert-manager with Let's Encrypt](how-to-cert-manager-lets-encrypt-ingress-api.md).
+
 1. If you follow the BYO deployment strategy, ensure that you set up your Application Gateway for Containers resources and ALB Controller ([Add-on](quickstart-deploy-application-gateway-for-containers-alb-controller-addon.md) or [Helm](quickstart-deploy-application-gateway-for-containers-alb-controller-helm.md))
 2. If you follow the ALB managed deployment strategy, ensure that you provision your ALB Controller ([Add-on](quickstart-deploy-application-gateway-for-containers-alb-controller-addon.md) or [Helm](quickstart-deploy-application-gateway-for-containers-alb-controller-helm.md)) and the Application Gateway for Containers resources via the [ApplicationLoadBalancer custom resource](quickstart-create-application-gateway-for-containers-managed-by-alb-controller.md).
 3. Deploy a sample HTTPS application:

articles/application-gateway/for-containers/migrate-from-agic-to-agc.md

@@ -227,6 +227,11 @@ Direct certificate upload and reference to a certificate in Azure Key Vault isn'
 
 Secrets should be stored in [AKS Secret Store](/azure/aks/concepts-security#kubernetes-secrets) and referenced by name.
 
+> [!IMPORTANT]
+> Application Gateway for Containers requires certificates to be local to the AKS cluster and cannot mount them from external volumes. As a result, using [Azure Key Vault with the Secrets Store CSI driver](/azure/aks/csi-secrets-store-driver) is not supported for Application Gateway for Containers certificates.
+>
+> To use certificates from Azure Key Vault, you must first sync them to Kubernetes secrets. Consider using [cert-manager](how-to-cert-manager-lets-encrypt-gateway-api.md) with Let's Encrypt for automated certificate management, or manually import certificates from Key Vault into Kubernetes secrets.
+
 ### Establishing backend certificate chain trust
 
 AGIC annotation

articles/application-gateway/ssl-overview.md

@@ -121,10 +121,10 @@ The following tables outline the differences in SNI between the v1 and v2 SKU in
 ### Frontend TLS connection (client to application gateway)
 
 
-|Scenario | v1 | v2 |
+| Scenario | v1 | v2 |
 | --- | --- | --- |
-| 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 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 |
 
 > [!NOTE]
@@ -138,15 +138,15 @@ The following tables outline the differences in SNI between the v1 and v2 SKU in
 #### For probe traffic
 
 
-|Scenario | v1 | v2 |
+| 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 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. |
+| 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 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
 
 
-|Scenario | v1 | v2 |
+| Scenario | v1 | v2 |
 | --- | --- | --- |
 | When an FQDN or SNI is available | The SNI is set using the backend server's FQDN. | 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** – SNI is set according to the following order of precedence: <br> a) Backend Setting’s hostname (as per Overridden value or Pick from backend server) <br> b) Host header of the incoming client request <br><br> 2. **Configurable** <br> Use specific SNI: Uses this fixed hostname for validation. <br> Skip SNI: No Subject Name validation. | 
 | When an FQDN or SNI is NOT available (only IP address is available) | SNI won't be set as per [RFC 6066](https://tools.ietf.org/html/rfc6066) if the backend pool entry isn't an FQDN | SNI won't be set as per [RFC 6066](https://tools.ietf.org/html/rfc6066). |