https://bz.apache.org/bugzilla/show_bug.cgi?id=70003
--- Comment #9 from [email protected] --- (In reply to Joe Orton from comment #8) > I had assumed it only makes sense to allow the third arg if "optional" is > used, and it should not be permitted otherwise. Otherwise we'd have to redo > and redefine the handling of "required" here. Using 'optional_no_ca' is currently the only way to allow an invalid client certificate at the moment but using this option also means that providing a client certificate in the first place becomes optional to complete the handshake. Having the second argument for 'require' as well, would allow for configurations where a client certificate is always required to complete the handshake, but the certificate itself can be invalid without causing the handshake to fail. >From what I understand, the question of whether a client certificate must be presented and whether this certificate must be valid or not are currently conflated with the 'optional_no_ca' option. The current behavior, as far as I know, is as follows: | Client Cert \ SSLVerifyClient | none | optional | require | optional_no_ca | |-------------------------------|------|----------|---------|----------------| | No Client Cert | TLS | TLS | error | TLS | | Client Cert (valid) | TLS | mTLS | mTLS | mTLS | | Client Cert (invalid) | TLS | error | error | mTLS | So, we could separate 'the requirement for a certificate' from 'whether the presented certificate must be valid or not'. This would allow for the following, simplified model: | Client Cert \ SSLVerifyClient | none | optional | require | |-------------------------------|-------|----------|---------| | No Client Cert | TLS | TLS | error | | Client Cert (valid) | TLS | mTLS | mTLS | | Client Cert (invalid) | TLS | error | error | And then, completely divorced from this, we can individually allow specific errors to be ignored through the second argument for both 'optional' and 'require'. The option 'optional_no_ca' would then remain, as you suggested, syntactic sugar for a combination of 'optional' and a backwards compatible list of ignored errors. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
