Hi all,
This patch also fixes a problem with stunnel accepting an "unknown" response
as "good" and allows the connection to be setup. An OCSP responder can
return one of three responses (good, revoked, unknown), however the code
would accept "unknown" as good. This patch fixes that problem and treats an
"unknown" response as a failure.
Stunnel can query an OCSP responder to determine the revocation status of a
certificate when stunnel is verifying the certificate. The code works
great, however it is uses a preconfigured OCSP responder. The OCSP
responder's IP/hostname is specified in the stunnel configuration file as a
URI. I found this rather restrictive, so I added code to extract the OCSP
responder's URI from the certificate.
As per RFC 3280, one of the valid extensions for X.509 certificate is the
Authority Information Access (AIA) where the "accessMethod" can be
"is-ad-ocsp" to identify the OCSP responders location as per RFC2560. There
can be more than one OCSP responder listed in the AIA because it is a
sequence. Each location is queried in the order they appear within the
certificate until either a "good" or "revoked" response is received. If an
"known" response or a failure then the next OCSP responder is checked. If
all OCSP responder queries result in failure then the validation also
fails..
A new configuration option "OCSPaia" was added. If the "OCSPaia=yes" then
the stunnel will look for the OCSP responder(s) within the certificate's
AIA. The locally configured "OCSP=<url>" overrides the OCSPaia option.
Bruce