Application Gateway OCSP in private network

Sepski, Krzysztof 0 Reputation points
2026-07-28T13:03:34.9333333+00:00

Hello,
I have a problem with using OCSP deployed in same VNET where is Application Gateway so could you please describe me how I should setup this?
Application Gateway and OCSP hosted in K8S cluser in same VNET - Test by openssl ocsp works fine, same certificate on Application gateway returns 400.
ERRORINFO_HTTPS_CERT_VERIFY_ERROR
FAILED:certificate status request failed

Azure Virtual Network
Azure Virtual Network

An Azure networking service that is used to provision private networks and optionally to connect to on-premises datacenters.

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Sina Salam 31,216 Reputation points Volunteer Moderator
    2026-07-29T13:15:28.5733333+00:00

    Hello Sepski, Krzysztof,

    Welcome to the Microsoft Q&A and thank you for posting your questions here.

    I understand that you're having issues with Application Gateway OCSP in private network.

    This is not caused by the private OCSP responder, VNet routing, DNS, or Kubernetes/OpenShift deployment, because you already confirmed that a self-signed certificate using the same OCSP URL successfully sends OCSP requests to the responder. Therefore, with the EJBCA-issued client certificate, its AIA OCSP extension, EKU/client authentication purpose, issuer chain, or the trusted client CA chain uploaded to Application Gateway.

    Application Gateway validates the presented client certificate by using the OCSP responder URL defined in the certificate’s Authority Information Access, AIA, extension. If the OCSP responder cannot be resolved/reached, or if certificate revocation validation cannot be completed, Application Gateway returns HTTP 400. - https://stackoverflow.com/questions/78541006/400-the-ssl-certificate-error-from-azure-application-gateway-with-mtls-setup-by, https://learn.microsoft.com/en-us/troubleshoot/azure/application-gateway/mutual-authentication-troubleshooting

    What you need to do to resolve is to:

    • Verify that the actual EJBCA client certificate contains a valid OCSP URI in the AIA extension.
    • Verify that the EJBCA client certificate has Extended Key Usage: TLS Web Client Authentication.
    • Upload the correct EJBCA trusted client CA chain to Application Gateway, including the issuing intermediate CA and root CA, but not the leaf certificate or private key.
    • Temporarily disable VerifyClientCertIssuerDN while testing, because issuer DN mismatch can cause Application Gateway to reject the client certificate before successful OCSP validation.
    • Keep VerifyClientRevocation set to OCSP.
    • Confirm the final result using the Application Gateway access log field sslClientVerify.

    After correcting the EJBCA certificate profile and trusted CA chain, Application Gateway should be able to build the client certificate chain, read the OCSP URI from AIA, send the OCSP request to the private responder, and complete the mTLS request successfully. Use the below resources for more reading and implementation steps:

    I hope this is helpful. Please! Do not hesitate to let me know if you have any other questions, steps or clarifications.

    Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-07-28T13:03:57.8266667+00:00

    FAILED:certificate status request failed with ERRORINFO_HTTPS_CERT_VERIFY_ERROR indicates Application Gateway could not complete the OCSP check for the certificate.

    For Application Gateway, OCSP validation depends on the OCSP responder URL in the certificate’s Authority Information Access (AIA) extension. The gateway must be able to resolve that FQDN and reach the responder over the network. If it cannot resolve the responder name or connectivity is blocked, Application Gateway returns HTTP 400 for mutual TLS requests.

    In this scenario, check the setup in this order:

    1. Verify the certificate contains the OCSP responder URL
      • Confirm the client certificate includes an AIA extension with a valid OCSP responder.
      • If the OCSP responder isn’t provided in the certificate, Application Gateway can return HTTP 400.
    2. Verify DNS resolution from the Application Gateway VNet
      • Application Gateway performs DNS resolution for customer-provided FQDNs, including the OCSP verification URL.
      • If the OCSP service is hosted privately in the same VNet, ensure the responder FQDN resolves correctly from that VNet.
      • If a private DNS zone is used, make sure it is linked to the VNet used by Application Gateway.
    3. Verify network connectivity from Application Gateway to the OCSP responder
      • Ensure traffic from the Application Gateway subnet to the OCSP responder is allowed.
      • If network connectivity is blocked to or from the responder, revocation status validation fails and Application Gateway returns 400.
    4. Check whether the first request is failing because of OCSP cache behavior
      • OCSP checks are validated via local cache based on the nextUpdate time from a previous OCSP response.
      • If the cache was not populated yet, the first response might fail. A retry can succeed after the response is cached.
    5. Confirm how revocation checking is configured
      • OCSP client revocation checking can be configured through REST API, ARM template, Bicep, CLI, or PowerShell.
      • Azure portal support for certificate revocation configuration is currently unavailable.
      • Example Azure CLI update for an existing gateway SSL profile:
    az network application-gateway update \
    --name ApplicationGateway01 \
    --resource-group ResourceGroup01 \
    --ssl-profiles [0].client-auth-configuration.verify-client-revocation=OCSP
    1. Use access logs to confirm OCSP evaluation
      • Access logs contain the sslClientVerify property, which shows the status of the OCSP response.
      • This is the best way to confirm whether the request failed because the responder was unreachable, missing from the certificate, or the certificate was considered revoked.

    Important points for this setup:

    • CRL-based revocation checking is not supported.
    • If Application Gateway cannot contact the OCSP responder, it returns HTTP 400.
    • If the responder URL is private, the responder name must still be resolvable and reachable from the Application Gateway deployment.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.