mod_ssl: Don't reject expired client certs with optional_no_ca.

[InterLinked1]

The SSLVerifyClient optional_no_ca setting has been broken since it was introduced in that expired certificates result in the request being rejected, which is contrary to the documentation and how the setting is supposed to behave. To fix this, add X509_V_ERR_CRL_HAS_EXPIRED to the list of error exceptions that allow ssl_callback_SSLVerify in ssl_engine_kernel.c and ssl_io_filter_handshake in ssl_engine_io.c to accept the client certificate anyways.

PR: 60028
PR: 60186

[InterLinked1]

@notroj Any chance you or a maintainer might be able to review this fix?

[notroj]

Thanks for the PR, I've pulled a fork to my user to get the CI run. https://github.com/notroj/httpd/actions/runs/15852142973

TBH I don't understand why specific errors are picked out as special by this macro. If the point is that all verification errors are "allowed" - as you say, this is what the docs imply - then... why don't we allow all verification errors?

[InterLinked1]

Thanks for the PR, I've pulled a fork to my user to get the CI run. https://github.com/notroj/httpd/actions/runs/15852142973

TBH I don't understand why specific errors are picked out as special by this macro. If the point is that all verification errors are "allowed" - as you say, this is what the docs imply - then... why don't we allow all verification errors?

Not necessarily opposed to that, just wanted to make the change as least disruptive as possible.

Also, I'm not sure all errors would make sense to ignore - looking through the list, some of them are more "fatal" errors, while ones like these that are exempted are cases where users may want to safely ignore something, mostly stuff having to do with properties on the cert / how it was signed.

[notroj]

Good points. I'm just thinking aloud... at least for 2.5/2.6 we should rename that to SSLVerifyClient untrusted or something less ambiguous/wrong than the current wording.