OpenLiteSpeed OCSP stapling verifier accepts rogue responder certificates with OCSP_NOVERIFY

[Jiho Kim]

OpenLiteSpeed's OCSP stapling verifier accepts a GOOD OCSP response for the configured server certificate even when the BasicOCSPResponse is signed by an unrelated, self-signed responder certificate embedded in the response. The issue is in the OCSP stapling verification path in src/sslpp/sslocspstapling.cpp: the code verifies the OCSP response with OCSP_NOVERIFY, then accepts the matching GOOD status and timestamps. A network attacker who can answer or alter the server's outbound HTTP OCSP refresh can cause OpenLiteSpeed to cache and staple an unauthorized response.

The flaw bypasses OpenLiteSpeed's own responder-authentication control. It does not, by itself, establish that a conforming TLS client will trust the forged GOOD status: clients independently validate a stapled OCSP response, and strict OpenSSL rejects the response used by the PoC. Depending on client policy, the invalid staple may instead be ignored or cause the TLS connection to fail (in particular where a valid staple is required).