Is OCSP Stapling supported?
Short answer
Yes. OCSP Stapling in the TLS Security Profile is turned on and the profile is assigned to the vService; TR7 obtains the OCSP response of the certificate by checking twice a day and attaches it for the client in the TLS handshake. For a response to be obtained, the certificate must contain an OCSP address and the issuing CA certificate must be in the certificate record's own content; if no response can be obtained, the certificate is presented without a staple. It is not applied to Backend Service connections or to certificates issued with TR7's internal CA.
How Does It Work?
- For the certificates of the vServices whose profile has OCSP stapling on, the OCSP response is obtained every day at 07:00 and 22:00 and a few minutes after the device starts; it is obtained not at the moment the profile is saved, but at the next scan.
- The response is validated; if the certificate status is good, it is stored and sent to the client in the handshake.
- When half of the validity period of the response has passed, a new one is obtained; a response with less than 6 hours left until the end of its validity is not sent.
- If no response can be obtained (no OCSP address, the issuing CA is not in the record, the responder cannot be reached, the status is not good), the certificate continues to be presented without a staple.
Requirements
| Requirement | Note |
|---|---|
| OCSP address in the certificate | The OCSP URL must be in the AIA extension of the certificate; some CAs (e.g. Let's Encrypt) no longer add this address |
| Issuing CA in the record | The intermediate certificate must be pasted in the Certificate Content field (fullchain) of the certificate record, or in the Intermediate Cert. Content field with Without Profile; a chain bound from the CA record with Use Profiles is not used when the OCSP response is obtained |
| Access to the OCSP responder | The device must have HTTP egress to the internet (or to the internal responder) |
Enabling in TR7
The Configuration Menu is opened with the TR7 logo at the bottom left; on the Certificates & PKI → TLS Security Profiles screen, the profile used by the vService is selected and Edit is clicked; for a new profile, Add is clicked and Security Profile Name is entered.
In the Frontend-only Settings section, OCSP Stapling is turned on (off by default).
Edit at the bottom of the form is clicked (Add for a new profile).
If the profile has not yet been assigned to the vService, on the Load Balancer → Load Balancer vService List screen, the vService is selected and Edit is clicked.
In the Details panel, the SSL Security box under Frontend Settings is checked and the profile from step 3 is selected (profile selection on the vService).
Save is clicked. In a cluster setup, with the default auto-sync, the change is also sent to the peer device; if Manual Sync Mode is on, it is sent to the peer device manually. Each device obtains the OCSP response itself.
In WEB-CLI, the same setting is made by updating the profile; in place of <profile>, the profile is selected with Tab (Connection behavior):
lb ssl-security update id <profile> --ocspStapling trueThe staple status is not shown in the interface; the check is performed from the client side.
Verification
After the next scan, from the client:
openssl s_client -connect 203.0.113.10:443 -servername www.example.com -status < /dev/nullIn the output, OCSP Response Status: successful and Cert Status: good are seen; if there is no staple, OCSP response: no response sent is written.
Common Misconceptions
- "The staple is sent the moment I turn it on." The response is obtained at the next scan (07:00 or 22:00).
- "OCSP stapling blocks a revoked certificate." If the certificate status is not good, only the staple is not sent; the certificate continues to be presented.
- "Client certificates are also checked with OCSP." In mTLS, no OCSP or CRL check is performed for client certificates (Can I authenticate clients with client certificates (mTLS)?).
How it is done in the documentation
