-
Notifications
You must be signed in to change notification settings - Fork 7.3k
SSL: optional ssl_client_certificate for ssl_verify_client. #143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSL: optional ssl_client_certificate for ssl_verify_client. #143
Conversation
@pluknet Kindly review this PR. Many deployments may have dependency on a.) this fix and b.) client certificate validation with OCSP. Kindly let me know, if you recommend breaking this into http, mail and stream. Thanks a ton in advance. |
2efaba7
to
1d2a16a
Compare
Hi Roman, It will be really helpful, if you can review this PR. We have a product, where we do not want to force user to configure the upper level config which maps to ssl_client_certificate in nginx for mTLS. Considering, from TLS1.1+ (rfc4346#section-7.4.4), it is not mandatory to send 'CA Issuer names' in 'certificate request' message from server to client in case on mTLS. So, It will be great if we can make ssl_client_certificate directive optional when ssl_trusted_certificate is configured. Thanks in advance for reviewing it. |
Suggested commit:
|
1d2a16a
to
4ea80fa
Compare
949d98e
to
7344f88
Compare
@pluknet Agree with the suggested commit as mentioned in thread. Pushed the same commit. Kindly review and merge. Thanks again. |
Over to @arut for the second review. |
Starting from TLSv1.1 (as seen since draft-ietf-tls-rfc2246-bis-00), the "certificate_authorities" field grammar of the CertificateRequest message was redone to allow no distinguished names. In TLSv1.3, with the restructured CertificateRequest message, this can be similarly done by optionally including the "certificate_authorities" extension. This allows to avoid sending DNs at all. In practice, aside from published TLS specifications, all supported SSL/TLS libraries allow to request client certificates with an empty DN list for any protocol version. For instance, when operating in TLSv1, this results in sending the "certificate_authorities" list as a zero-length vector, which corresponds to the TLSv1.1 specification. Such behaviour goes back to SSLeay. The change relaxes the requirement to specify at least one trusted CA certificate in the ssl_client_certificate directive, which resulted in sending DNs of these certificates (closes nginx#142). Instead, all trusted CA certificates can be specified now using the ssl_trusted_certificate directive if needed. A notable difference that certificates specified in ssl_trusted_certificate are always loaded remains (see 3648ba7). Co-authored-by: Praveen Chaudhary <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
redid -> redone in the commit log.
Otherwise looks ok.
7344f88
to
7a59f43
Compare
Addressed review comments. |
Starting from TLSv1.1 (as seen since draft-ietf-tls-rfc2246-bis-00),
the "certificate_authorities" field grammar of the CertificateRequest
message was redid to allow no distinguished names. In TLSv1.3, with
the restructured CertificateRequest message, this can be similarly
done by optionally including the "certificate_authorities" extension.
This allows to avoid sending DNs at all.
In practice, aside from published TLS specifications, all supported
SSL/TLS libraries allow to request client certificates with an empty
DN list for any protocol version. For instance, when operating in
TLSv1, this results in sending the "certificate_authorities" list as
a zero-length vector, which corresponds to the TLSv1.1 specification.
Such behaviour goes back to SSLeay.
The change relaxes the requirement to specify at least one trusted CA
certificate in the ssl_client_certificate directive, which resulted in
sending DNs of these certificates (closes #142). Instead, all trusted
CA certificates can be specified now using the ssl_trusted_certificate
directive if needed. A notable difference that certificates specified
in ssl_trusted_certificate are always loaded remains (see 3648ba.)
Proposed changes
As per below RFCs, ssl_client_certificate should be optional with TLS1.1+ when ssl_verify_client is configured as on/optional:
TLS1.3: rfc8446#section-4.2.4:
TLS1.2: rfc5246#section-7.4.4:
TLS1.1: rfc4346#section-7.4.4: Similar wording as TLS 1.2.
TLSv1.0: rfc2246#section-7.4.4: It was not clearly defined in v1.0, that CA list in certificate request message can be empty or not.
Also Nginx documentation seems to suggest the same:
**Tested with nginx-tests.
Verified after deploying on Debian.**
Relevant Config
With ssl_protocols TLSv1.2 TLSv1.3;
Comment ssl_trusted_certificate in nginx config.