How do I inform Microsoft of a failure of their OCSP service that is currently returning 500 Internal Server Error?

Question

How do I inform Microsoft of a failure of their OCSP service that is currently returning 500 Internal Server Error?

Kevin Collins 25

Microsoft's OCSP service, is currently broken, returning a "500 Internal Server Error".

Since it doesn't seem possible to actually submit a general support request anymore, I'm hoping that maybe someone will see this here and route this notification to the right folks--it is causing some issues with validating certificates from the Azure IMDS metadata service.

📝 EDIT 2025-11-12: As I mentioned further below, you cannot conclude failure of this service purely on a simple HTTP GET. There was an issue that was corrected. See the answer post for more details on a correct test/evaluation process.

Kevin Collins 25

It is still broken at the time of writing:

Certificate validation (that include default revocation checks) of Azure IMDS attested data document signing certificate are currently failing.

Below is a snippet of logs (with certpath debugging enabled) showing a malformed request (i.e. the HTTP 500 response) coming back when it tries to connect to the OCSP endpoint referenced by the Azure IMDS certificate:

...
INFO   | jvm 1    | 2025/11/11 20:53:29 | certpath: -Using checker7 ... [sun.security.provider.certpath.RevocationChecker]
INFO   | jvm 1    | 2025/11/11 20:53:29 | certpath: RevocationChecker.check: checking cert
INFO   | jvm 1    | 2025/11/11 20:53:29 |   SN: 33:03:02:3b:f6:96:d8:d0:d5:84:80:51:91:00:00:03:02:3b:f6
INFO   | jvm 1    | 2025/11/11 20:53:29 |   Subject: CN=metadata.azure.com, O=Microsoft Corporation, L=Redmond, ST=WA, C=US
INFO   | jvm 1    | 2025/11/11 20:53:29 |   Issuer: CN=Microsoft Azure RSA TLS Issuing CA 04, O=Microsoft Corporation, C=US
INFO   | jvm 1    | 2025/11/11 20:53:29 | certpath: connecting to OCSP service at: 
INFO   | jvm 1    | 2025/11/11 20:53:29 | certpath: OCSP response status: MALFORMED_REQUEST
...

Answer accepted by question author

0 additional answers

Your answer

Kevin Collins 25 Reputation points

2025-11-11T23:40:11.0366667+00:00

It is still broken at the time of writing:

Certificate validation (that include default revocation checks) of Azure IMDS attested data document signing certificate are currently failing.

Below is a snippet of logs (with certpath debugging enabled) showing a malformed request (i.e. the HTTP 500 response) coming back when it tries to connect to the OCSP endpoint referenced by the Azure IMDS certificate:

... INFO | jvm 1 | 2025/11/11 20:53:29 | certpath: -Using checker7 ... [sun.security.provider.certpath.RevocationChecker] INFO | jvm 1 | 2025/11/11 20:53:29 | certpath: RevocationChecker.check: checking cert INFO | jvm 1 | 2025/11/11 20:53:29 | SN: 33:03:02:3b:f6:96:d8:d0:d5:84:80:51:91:00:00:03:02:3b:f6 INFO | jvm 1 | 2025/11/11 20:53:29 | Subject: CN=metadata.azure.com, O=Microsoft Corporation, L=Redmond, ST=WA, C=US INFO | jvm 1 | 2025/11/11 20:53:29 | Issuer: CN=Microsoft Azure RSA TLS Issuing CA 04, O=Microsoft Corporation, C=US INFO | jvm 1 | 2025/11/11 20:53:29 | certpath: connecting to OCSP service at: INFO | jvm 1 | 2025/11/11 20:53:29 | certpath: OCSP response status: MALFORMED_REQUEST ...

Answer 1

Jilakara Hemalatha 12,755 Microsoft External Staff Moderator

Thank you for your patience and for reporting this issue.

We verified this internally with the Engineering team, and they confirmed that there was a recent service-side issue impacting the Microsoft OCSP responder, which affected certificate validation for some customers. The issue has now been resolved on the service platform.

If you are still experiencing HTTP 500 errors or certificate validation failures, this may be due to cached OCSP responses or stalled certificate validation states on the client side. Although the backend service is now healthy, some environments may take additional time to clear cached OCSP results.

If any certificate validation failures persist at the application level, they may still be related to local cached OCSP responses or certificate validation state on the client side.

Could you please check and let us know if the issue still persists? We will be happy to assist you further.

Kevin Collins 25

As of this morning, I can confirm that the issue appears to have been resolved, thank you! Here is a fresh debug snippet from the actual application this morning:

INFO   | jvm 1    | 2025/11/12 17:20:55 | certpath: -Using checker7 ... [sun.security.provider.certpath.RevocationChecker]
INFO   | jvm 1    | 2025/11/12 17:20:55 | certpath: RevocationChecker.check: checking cert
INFO   | jvm 1    | 2025/11/12 17:20:55 |   SN: 33:02:97:6e:aa:10:01:48:78:35:dc:86:6e:00:00:02:97:6e:aa
INFO   | jvm 1    | 2025/11/12 17:20:55 |   Subject: CN=metadata.azure.com, O=Microsoft Corporation, L=Redmond, ST=WA, C=US
INFO   | jvm 1    | 2025/11/12 17:20:55 |   Issuer: CN=Microsoft Azure RSA TLS Issuing CA 08, O=Microsoft Corporation, C=US
INFO   | jvm 1    | 2025/11/12 17:20:55 | certpath: connecting to OCSP service at: 
INFO   | jvm 1    | 2025/11/12 17:20:55 | certpath: OCSP response status: SUCCESSFUL
INFO   | jvm 1    | 2025/11/12 17:20:55 | certpath: OCSP response type: basic
INFO   | jvm 1    | 2025/11/12 17:20:55 | certpath: Responder ID: byKey: 5B0793AD543F72CC74E9B65BD50E77B07B0D2B75
INFO   | jvm 1    | 2025/11/12 17:20:55 | certpath: OCSP response produced at: Wed Nov 12 17:16:20 UTC 2025
INFO   | jvm 1    | 2025/11/12 17:20:55 | certpath: OCSP number of SingleResponses: 1

I realized today that a simple GET to that address still produces a 500, perhaps that is due to not interacting with it via a proper OCSP check.

Manual testing with openssl ocsp (after retrieving the issuer and certificate from the attested data document, see here) is now successful as well:

$ openssl ocsp --issuer intermediate.pem -cert signer.pem -text -url http://oneocsp.microsoft.com/ocsp
OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: 1BC66318D19B621575EEB02B7469CD52D59A2AE2
          Issuer Key Hash: F67E2FBD80A34AB2705BEBDF9A1FD8EDCA618007
          Serial Number: 3302976EAA1001487835DC866E000002976EAA
    Request Extensions:
        OCSP Nonce:
            04102A98239ADA8C9A15D25A3478EADC8E17
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: 20CDA26935B44DACD6836889E3D3293A8F834DD5
    Produced At: Nov 12 17:30:22 2025 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 1BC66318D19B621575EEB02B7469CD52D59A2AE2
      Issuer Key Hash: F67E2FBD80A34AB2705BEBDF9A1FD8EDCA618007
      Serial Number: 3302976EAA1001487835DC866E000002976EAA
    Cert Status: good
    This Update: Nov 12 14:13:08 2025 GMT
    Next Update: Nov 20 14:33:08 2025 GMT
...
Response verify OK
signer.pem: good
	This Update: Nov 12 14:13:08 2025 GMT
	Next Update: Nov 20 14:33:08 2025 GMT

In the future, use this technique to gauge operation of the OCSP service if it is in question.

Jilakara Hemalatha 12,755 Reputation points Microsoft External Staff Moderator

2025-11-12T18:18:12.49+00:00

Hi @Kevin Collins

Thank you for the detailed update and for sharing the logs and validation results.

We are glad to hear that the issue is now resolved and that your application is receiving successful OCSP verification responses

Share via

How do I inform Microsoft of a failure of their OCSP service that is currently returning 500 Internal Server Error?

0 additional answers

Your answer