On Friday, June 30, 2017 at 3:11:36 PM UTC-4, Filippos Slavik wrote:
> Thanks, for the comment, however, I did not use the synopsis 100% as-is. As noted in my initial comment, the test code is reading the cert in an init_by_lua* block and caches the parsed certificate, in DER format, in a global LUA table that is then used by the worker to look up the cert and set it during SSL handshake (with set_der_cert & set_der_priv_key). I've used both global LUA table and LRU cache to test, with no significant difference in overall performance. I've used both global LUA table and LRU cache to test, with no significant difference in overall performance.
Yes I understand, but there will still be a performance hit with that strategy. OpenResty supports multiple hooks/formats of SSL certs.
* PEM is converted to DER via `cert_pem_to_der`, then activated via `set_der_cert`. The DER can be cached via lua-resty-lrucache (worker) or lusa_shared_dict (shared for all processes)
* PEM is converted to cdata pointer via `parse_pem_cert`, then activated via `set_cert`. The cdata pointer can be cached via lua-resty-lrucache (worker)
Using a cached value from `parse_pem_cert` via `set_cert` is much more performant than using a cached value from `cert_pem_to_der` via `set_der_cert` -- but you can only cache within a worker, not shared across a process.
The `parse_pem_cert` + `set_cert` combo is closer to what nginx does with files based certs.
When you use `cert_pem_to_der`, you're only caching a preliminary transcode. `set_der_cert` still has to read/process the certificate, it's just doing so from DER format.
The reason why there are these two hooks is because historically, certificate loading was via DER format. The PEM->DER conversion was a convenience method, as certificates are commonly stored/distributed/archived in PEM format. A year or two ago, someone was nice enough to write lower-level hooks into the SSL logic and bypass the whole certificate loading/transcoding logic.
