@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.
Syeda Persia Aziz
Software DeveloperYahoo! (Oath).Champaign, Illinois
On Tuesday, March 27, 2018, 5:43:10 PM CDT, Leif Hedstrom
<[email protected]> wrote:
> On Mar 27, 2018, at 4:36 PM, Alan Carroll <[email protected]>
> wrote:
>
> Persia should correct me if I'm wrong, but my understanding is the default
> is no handling. The ATS core provides a default handler for OCSP and the
> point of this call is to set this context to use the ATS core default OCSP
> handler. That is how this makes OCSP easier for plugins - rather than
> writing a handler, the handling is delegated to the default handler in the
> ATS core. I'm open to better name suggestions, a name which conveys the
> concept "use the ATS core default OCSP handler for this context".
Ah so this is for certificates (contexts) loaded via a plugin, and not the
normal ssl_multicert.config way? Curious: Are we not using some API to “add”
the context into the ATS handling of certificates? If so, couldn’t this be done
implicitly by that API / UI or whatever it is? I.e. if a plugin hands ATS a new
context, ATS calls the appropriate OpenSSL code to enable the default handling,
much like it does when we load certificates via ssl_multicert.config?
— leif
