OSCP request cache time

Question

OSCP request cache time

Ruslan Mullagaliev 0

Hello, everyone!

I recently added an OSCP check to the Azure Application Gateway because we use mTLS to communicate with the tablet. It's working well, but as far as I know, the AGW uses a cache mechanism to store the answer from the OCSP server for between 4 and 24 hours, depending on the nextUpdate value. How can I check this value?

Second, are AGW logs expected to not store declined requests with absent or revoked certificates? In the AccessLog and FirewallLog, I only see successful requests, even though I receive a 400 error in the browser for both scenarios.

Thanks in advance!

Praveen Bandaru 5,520 Reputation points Microsoft External Staff Moderator

2025-07-01T08:13:41.38+00:00
Hello Ruslan Mullagaliev

I understand that you are conducting an OSCP review for your Azure Application Gateway and have some questions regarding its caching behavior and logging features.

Azure Application Gateway does cache OCSP check responses, and this caching can be influenced by the nextUpdate value. To view the cache settings or the current value, you generally need to check the application's configuration, since the Azure Portal or CLI does not provide a direct way to access OCSP cache settings.

You can use tools like OpenSSL to manually inspect the OCSP responses. Here's a basic example of how you might do this:

openssl ocsp -issuer issuer.crt -cert client.crt -url http://ocsp.server.url -resp_text

Alternatively, you could use Wireshark or a similar tool to capture OCSP traffic and review the response headers.

Monitoring cache behavior is usually done through application logs or by reviewing the gateway's configuration and applied policies.

Regarding the 400 error, you can try the following suggestion:

Make sure you have set up diagnostic settings to collect detailed logs, which can be configured in the Azure portal under the Application Gateway's diagnostic settings.

In the Application Gateway diagnostic logs, you will find both successful and 400 error logs. Make sure to check the correct timestamps and use the appropriate query.

Use the below query to check the application gateway and Application Gateway Firewall Log:

AzureDiagnostics | where ResourceProvider == "MICROSOFT.NETWORK" and Category == "ApplicationGatewayLog"

AzureDiagnostics | where ResourceProvider == "MICROSOFT.NETWORK" and Category == "ApplicationGatewayFirewallLog"

Check the reference public document:

https://learn.microsoft.com/en-us/azure/application-gateway/log-analytics#explore-data-with-examples

Access logs should record all requests, including those that are declined. If declined requests aren't appearing, consider adjusting the logging level or settings.

Firewall logs should also capture all traffic, including blocked requests. Verify that your Web Application Firewall (WAF) policies are set to log all necessary events.

You can use Azure Monitor and Log Analytics to review and analyze your logs, creating custom queries to locate declined requests.

Check the public documents:

Diagnostic logs for Application Gateway

Monitor Azure Application Gateway

Monitor logs for Azure Web Application Firewall

Hope the above answer helps! Please let us know do you have any further queries.

Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Ruslan Mullagaliev 0 Reputation points

2025-07-01T08:53:33.85+00:00

@Praveen Bandaru Thanks for the response, but it didn't work. I'm sending all logs and metrics from AGW to Azure Log Analytics workspace. I see a request with code 200, but requests with code 400 ("Bad Request" and "No required SSL certificate was sent") do not appear in either the AccessLog or the FirewallLog.
G Sree Vidya 3,100 Reputation points Microsoft External Staff Moderator

2025-07-03T19:53:37.39+00:00
Hi Ruslan Mullagaliev

Thank you for providing additional details about sending Azure Application Gateway (AGW) logs and metrics to an Azure Log Analytics workspace and the issue where requests with HTTP 400 errors ("Bad Request" or "No required SSL certificate was sent") are not appearing in the ApplicationGatewayAccessLog or ApplicationGatewayFirewallLog, while 200 OK requests are logged.

Could you please try these suggestions to Capture 400 Errors:

Azure Monitor Metrics: Use AGW metrics in Azure Log Analytics, such as FailedRequests or TotalRequests, to indirectly track 400 errors. These metrics aggregate failed connections, including TLS handshake failures, but do not provide detailed request-level information (e.g., specific error messages like "No required SSL certificate was sent").

Diagnostic Settings: Ensure diagnostic settings are configured to send all available log categories (ApplicationGatewayAccessLog, ApplicationGatewayFirewallLog, ApplicationGatewayPerformanceLog) to Log Analytics. However, TLS handshake errors are unlikely to appear in these logs.

Verify that diagnostic settings in Log Analytics include all AGW log categories. Run a KQL query in Log Analytics to confirm no 400 errors are logged: kql
ApplicationGatewayAccessLog | where HttpStatusCode == 400

Network Tracing: Use external tools like Wireshark or browser developer tools to capture TLS handshake failures at the client side, confirming 400 errors for absent or revoked certificates.

Custom Solution: Deploy a reverse proxy or load balancer (e.g., NGINX) in front of AGW to log TLS handshake failures. This is not natively supported by AGW and requires additional infrastructure.

Why 400 Errors Are Not Logged, when the requests resulting in HTTP 400 errors due to mTLS failures (e.g., "Bad Request" or "No required SSL certificate was sent") occur at the TLS handshake layer before the HTTP request is fully processed.

Azure Application Gateway’s ApplicationGatewayAccessLog and ApplicationGatewayFirewallLog primarily capture HTTP-level transactions that reach the application layer. Since mTLS validation (including OCSP checks for revoked certificates or missing certificates) happens during the TLS handshake, these failures are terminated early and do not generate entries in the standard AccessLog or FirewallLog.

I hope this information helps! Do let me know if you have further queries.
KapilAnanth-MSFT 49,626 Reputation points Microsoft Employee Moderator

2025-07-07T15:20:09.7333333+00:00
@Ruslan Mullagaliev ,

Adding to the points of my colleagues G Sree Vidya and Praveen Bandaru,

The 400 error should be logged.

See : Access log category

Especially the parameters "error_info" and "sslClientVerify"

Also see

As next steps,

Please share the exact KQL query you are using

Run the Kusto query without any filters and see if the 400 requests are captured

Refer : Troubleshooting mutual authentication errors in Application Gateway

Hope this helps

Thanks,

Kapil

Your answer

Ruslan Mullagaliev 0 Reputation points

2025-07-01T08:53:33.85+00:00

@Praveen Bandaru Thanks for the response, but it didn't work. I'm sending all logs and metrics from AGW to Azure Log Analytics workspace. I see a request with code 200, but requests with code 400 ("Bad Request" and "No required SSL certificate was sent") do not appear in either the AccessLog or the FirewallLog.
KapilAnanth-MSFT 49,626 Reputation points Microsoft Employee Moderator

2025-07-07T15:20:09.7333333+00:00

@Ruslan Mullagaliev ,

Adding to the points of my colleagues G Sree Vidya and Praveen Bandaru,

The 400 error should be logged.

See : Access log category

Especially the parameters "error_info" and "sslClientVerify"

Also see

As next steps,

Please share the exact KQL query you are using

Run the Kusto query without any filters and see if the 400 requests are captured

Refer : Troubleshooting mutual authentication errors in Application Gateway

Hope this helps

Thanks,

Kapil

Share via

OSCP request cache time

Your answer