Inconsistent OCSP Staple behaviour with Azure Frontdoor CDN - staple missing

Question

I have an azure front door instance with multiple routes configured. We use frontdoor managed certificates

I've had a pen test performed with some findings around the tls certificate, namely OCSP Staple not enabled.

This was confusing to me as the docs say front door supports it without any configuration: https://learn.microsoft.com/en-us/azure/frontdoor/end-to-end-tls?pivots=front-door-standard-premium#online-certificate-status-protocol-ocsp-stapling

So to confirm this behaviour I run the following:

openssl s_client -connect <subdomain.mysite>.com.au:443 -status -servername <subdomain.mysite>.com.au

Each time I run the above I consistently get the OCSP stapled response:

OCSP response:

OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: A5B4D6EB36C4E76BA6DFC4640B012A2004B86623 Produced At: Nov 25 14:12:43 2024 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: 98F90032A9C065EB3C4FA8510E4C8DB8A7101603 Issuer Key Hash: A5B4D6EB36C4E76BA6DFC4640B012A2004B86623 Serial Number: 0582321FDE9A3732A0FC417B6E0AAC08 Cert Status: good This Update: Nov 25 13:57:02 2024 GMT Next Update: Dec 2 12:57:02 2024 GMT

However despite the above, I was able to reproduce the pen testers findings when using ssl testing tools, like https://github.com/drwetter/testssl.sh, or Qualys https://www.ssllabs.com/ssltest/

Both of these report ocsp stapling was not offered. Subsequent runs may have the response stapled.

The above is the diff of 2 runs of the testssh.sh output in json. Note the inconsistency.

I would like adopt OCSP Must-staple at some point, however this is impossible if we aren't getting consistent ocsp stapling.

Answer 1

@Alek Ivankovic ,

Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

I understand that you would like to know if Online Certificate Status Protocol (OCSP) stapling is supported or not in AFD.

I did a few testing using https://www.ssllabs.com/ssltest/ and I could see Revocation status as Good (not revoked) only

• I tried with your site
• And careers.microsoft.com as well

However, in both the cases, I see "OCSP Must Staple" is set as "No"

• Can you please confirm if there was a "Yes" in the above?
• During one of your testing?

Meanwhile, I shall check this once with the Product team and report back here.

Update :

Mitch Hirsch , @Alek Ivankovic ,

• We did a Lab with openSsl and sslscan utility, I was not able to see consistent results (with OCSP Stapling offered)
• Also, from the browser, I can see Authority Information Access
  • 

The potential reason that SslLabs could be pointing that OCSP must staple is "No" because in first request to AFD, will not have OCSP response cached for the machine. So, it'll not respond with stapled OCSP response. For subsequent requests until cache is not evicted, responses will have the OCSP status.

The Product Team is aware of such behavior, and are working on it (as of now, we don't have an ETA)

Hope this helps.

 

Cheers,

Kapil

---

Please Accept an answer if correct.

Original posters help the community find answers faster by identifying the correct answer.