It's better not bind `X509_STORE_set_flags` logic in `store:add(crl)` about lua-resty-openssl HOT 4 CLOSED

@catbro666 It will make more sense to let user to control the flag if we are working on a much low-level API (for example, a one-to-one wrapping of X509_STORE openssl api into Lua). But most of the functions in this library are designed to use by end user, in this case it's better to keep the API as simple as possible. Asking user had to call two API for CRL check but only one for trusted chain is inbalanced.

I do see the use case from mtls-auth plugin, but generally speaking, the case of "add a CRL but not use it verification" is far less common then "add a CRL and use it verification". So I would incline to keep it as is.

from lua-resty-openssl.

@fffonion Agree with high-level API should be easy to use and good by default. Setting this flag by default does make sense, but at least we should leave the possibility for the end user to not set it. The flag is not so easy to be unset, so what could have been done with one store now has to be done with two stores. OpenSSL doesn't provide direct wrapping API for unsetting flags on X509_STORE_CTX level, but does have X509_VERIFY_PARAM_clear_flags. Maybe we can extend store:verify with a clear_flags parameter to support this.

from lua-resty-openssl.

I get a more compelling reason now. There may be several independent CAs in the store and each CA can have its own CRL. If we add the crl of ca1 into the store, and the api automatically set the flag to the store. Then when we verify the client cert issued by ca2, it will fail with "unable to get certificate CRL"

from lua-resty-openssl.

In that case you shoudn't be adding the CRL of ca1 in the first place: only add what you intend to be verify upon later.

from lua-resty-openssl.