fffonion
Change order in ssl_certificate
Hi,
We're looking at using this internally and I was wondering around the order of actions in ssl_certificate
At present you check if the certificate is whitelisted before serving the certificate.
Is there any reason why you don't swap those two actions around?
IE
- check if you have a valid certificate, if you do serve it.
- Check if it needs to be created (if it doesnt return)
- If you does then check if it is whitelisted (bail out if it isnt)
- Create it
This seems it would solve the issues around the slower times when using dynamic whitelists as it would only be checked if there isn't a valid certificate.
Hi @cdloh, your thoughts make sense to me. Though I'd think always checking the whitelist first would be easier to make it as a single source of truth of which domains are allowed. For example, if we check the storage first, it won't be possible to disable a domain that is previously allowed, without deleting it from storage. Normally the dynamic whitelist check routine should be kept slim and fast. You'll feel checking storage for valid certificate is faster because we cache them locally to save network operations. So it'd probably make sense to do the same for you dynamic whitelist routine, that to utilize a local cache to make it faster on each request.
Fair enough. I can see the benefit there.
I'll test it further in anger to see if I find any issues.
I would argue that disabling a certificate would happen fairly rarely? And the benefit of speeding up ALL SSL connections vs having the steps to manually clean a certificate would outweigh each other.
Generally such hot path that requires network would needs to be cached. There's a great library I would suggest to use https://github.com/thibaultcha/lua-resty-mlcache, if you don't want to implement your own caching mechanism.