A secure connection involves more than receiving a certificate. A client may also need information about whether that certificate has been revoked. OCSP stapling is a way for the server to supply a signed status response during the connection process, rather than leaving every client to make a separate status request.
The OCSP specification, RFC 6960, defines responses about certificate status and the requirements for signing them. The server carrying a response is not thereby becoming the authority that issued the status statement.
Separate carrying the response from trusting it
Think of the server as delivering a signed document. The client still has to evaluate whether the response is valid, relevant to the certificate and acceptable under its policy. Merely receiving extra bytes does not make a connection trustworthy.
This is also separate from checking the certificate’s chain, name and validity period. Stapling contributes status information; it does not replace the rest of certificate validation or prove that the website’s content is honest.
The handshake format depends on TLS
RFC 8446’s certificate-status section explains that TLS 1.3 carries OCSP information in an extension associated with the certificate entry. Earlier TLS versions used a different message arrangement. That distinction matters when reading a packet trace or an older tutorial.
For a learning exercise, identify the certificate, the status response and the protocol version as separate items. Note which tool produced the output. Avoid treating a missing line in one diagnostic tool as a complete explanation of a browser’s decision.
Check the current service before changing a configuration
Certificate authorities and clients can use different revocation mechanisms and policies. Whether stapling is available or useful depends on the certificate provider, server software and client behaviour. Consult their current documentation before copying a configuration from an old guide.
If troubleshooting, record the certificate issuer, server version, response timestamps and the exact error. Those details help distinguish a stale response from an unsupported arrangement or a different validation failure.
The central idea is modest but useful: a server can deliver certificate-status evidence during a handshake, while the client remains responsible for deciding what that evidence means.