After debugging, I found that TSSslServerContextCreate does not configure the 
ssl context with the ocsp data. So I had to make another API, for the OCSP to 
work for contexts created by plugin. I will make a PR

 Following is the newly proposed API. I need to test this more. 

```tsapi TSReturnCode
TSSslInitOCSPStapling(TSSslContext ctx, X509 *cert, char* certname, char 
*servername)
{

  auto sslCTX             = reinterpret_cast<SSL_CTX *>(ctx);

  if (SSL_CTX_set_tlsext_status_cb(sslCTX, ssl_callback_ocsp_stapling)) {

    SSLConfigParams *params = SSLConfig::acquire();
    SSLCertLookup *lookup = SSLCertificateConfig::acquire();

    if ((!SSL_CTX_load_verify_locations(sslCTX, params->serverCACertFilename, 
params->serverCACertPath)) ||
       (!SSL_CTX_set_default_verify_paths(sslCTX))) {
     SSLError("invalid CA Certificate file or CA Certificate path");
    }
    if (!ssl_stapling_init_cert(sslCTX, cert, certname)) {
      Warning("fail to configure SSL_CTX for OCSP Stapling info for certificate 
of %s", (const char *)certname);
    }
    else if (lookup != nullptr) {
      lookup->insert(servername,SSLCertContext(sslCTX));
    }
    SSLCertificateConfig::release(lookup);
    SSLConfig::release(params);
    return TS_SUCCESS;
  }

  return TS_ERROR;
}```

Syeda Persia Aziz
Software DeveloperYahoo! (Oath).Champaign, Illinois 

    On Wednesday, March 28, 2018, 10:35:57 AM CDT, Leif Hedstrom 
<zw...@apache.org> wrote:  
 
 

> On Mar 27, 2018, at 9:52 PM, Persia Aziz <persia.a...@yahoo.com> wrote:
> 
> 
> @Leif,
> 
> Yes, this is for certificated loaded via plugin. I don't know of any such API 
> to hand a new context to ATS. Again, looking at the code, the ocsp is enabled 
> on a context only at the initialization phase. So any context created 
> externally in a plugin does not get configured with the global ATS 
> configuration.


This is way outside my area of expertise, but it seems we already have

    tsapi TSSslContext TSSslServerContextCreate(void);


So why can’t we setup the OCSP default callback handler in that existing API? 
Having two APIs each doing part of the context “initialization” seems 
unnecessary. Heck, even if we needed to add new parameters to 
TSSslServerContextCreate() that would be fine, since we can break API / ABI 
compatibility in v8.0.

Cheers,

— Leif

  

Reply via email to