curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Expanding Certificate Revocation Check Capabilities in cURL using OCSP

From: Harsh Chaturvedi via curl-library <>
Date: Wed, 30 Oct 2019 14:40:02 -0700

Hello All,

Some context - cURL is the main communication library used in Snowflake's
ODBC driver. We rely on OCSP as our main revocation check protocol and
since cURL is shipped with only parsing stapled OCSP responses, we have
written our own custom OCSP response fetch/extract/parse capabilities.

The existing stapled OCSP response parsing does not work for us. Even
though ocsp stapling is great, it has not seen a lot of traction with a lot
of PaaS / IaaS providers we use.

Since the code is custom fit to Snowflake's infrastructure, there is little
value in requesting to add it to cURL so we ship Snowflake's connectors
with our own supplemented copy of cURL library. This process however adds
update challenges as one might have guessed. Instead of continuously being
able to update cURL libs, we have to go through multiple checks and
balances that are in place to ensure no regression.

Would it be possible to add a callback (similar to
CURLOPT_SSL_CTX_FUNCTION) that allows a developer to specify their own
Revocation check mechanism? The default can still point to the stapled OCSP
response parsing but if a user wants to expand the capabilities they can
point their own function. The callback can look something like this:

*** curl_rev_check_callback
*** data - connection data
*** cc - certificate chain for revocation validation
*** st - local cert store
CURLCode ( * curl_rev_check_callback ) ( struct connectdata *data,
STACK_OF(X509) cc, X509_STORE st)

Harsh Chaturvedi
Software Engineer,
Client Security,
Snowflake Computing

Received on 2019-10-30