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