status_request
status_request asks the server to staple an OCSP response proving its certificate is not revoked. Browsers send it.
What it is
status_request (extension 5), defined in RFC 6066, is how a client asks for OCSP stapling. Instead of the client contacting the certificate authority to check whether the server certificate has been revoked, the server fetches a signed OCSP response itself and attaches it to the handshake.
Stapling is faster and more private than live OCSP checks: the client makes no extra request, and the certificate authority does not learn which sites the client visits.
The extension can name the OCSP responders the client trusts. An empty list means the server decides which responder to use. If the server has no stapled response, the handshake simply continues without one.
For servers, enabling OCSP stapling is mostly a configuration switch in nginx, Apache or a CDN, and it saves visitors a lookup on every new connection.
Who sends it
Measured on 2026-10-25 against our own test server: sent by 5 of 12 clients. Position counts from 1 and ignores GREASE values.
Why it matters for fingerprinting
Chrome, curl_cffi, both curl-impersonate profiles and Go net/http send it. curl, Python requests, httpx, Node.js fetch and Guzzle do not. curl_cffi sends it as its very first extension, while it was 15th in our Chrome capture, because Chrome shuffles extensions and curl_cffi does not.
Check whether your client sends it
Open the test from your browser, or call it from your script, and look for status_request in the TLS details.
Run the TLS fingerprint test