Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@willmafh
Copy link
Contributor

@willmafh willmafh commented Feb 25, 2025

Proposed changes

feature: #554

  • Add $ssl_sigalg variable to get signature algorithm used for signing messages during tls handshake

  • Add $ssl_peer_sigalg variable to get signature algorithm the peer used for signing messages during tls handshake

  • we can use both of them in log to know more details about the tls handshake

The variable contains the signature algorithm used for signing messages
during the handshake.
The variable contains the signature algorithm the remote peer used for
signing messages during the handshake and at the local side, we can use it
to verify the peer's signature.
@ghen2
Copy link

ghen2 commented Aug 13, 2025

Perhaps $ssl_client_sigalg is more consistent with existing $ssl_client_* variables?

Copy link
Contributor

@pluknet pluknet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the server side, I don't see the added value: whoever made a setup is used to know which certificates he is willing to use;
that's why there's no similar server-side variables in nginx.

So, what the change usefully aims to add is ability to obtain the name of the signature
used by the client to sign TLS messages.
Note that it can be only useful with client certificate validation enabled as this information is served (indirectly) from a passed client certificate.
That said, the variable name should be prefixed with "$ssl_client_", similar to other such.

Further, I see a little benefit in using ASN1 object naming, which can be rather cryptic, such as for "id-ecPublicKey".
In this regard, IANA names are preferred and would be nice to have instead.
This is possible by using SSL_get0_peer_signature_name() introduced in OpenSSL 3.5 specifically for this purpose, i.e. logging.

@ghen2
Copy link

ghen2 commented Aug 18, 2025

For the server side, I don't see the added value: whoever made a setup is used to know which certificates he is willing to use; that's why there's no similar server-side variables in nginx.

It is useful for servers to have and log, when offering multiple certificates (RSA and ECC, or future PQC certificates), to know which of them are negotiated by clients, as with TLS 1.3, the signature algorithm is no longer part of the $ssl_cipher name.

@willmafh
Copy link
Contributor Author

willmafh commented Sep 6, 2025

For the server side, I don't see the added value: whoever made a setup is used to know which certificates he is willing to use; that's why there's no similar server-side variables in nginx.

It is useful for servers to have and log, when offering multiple certificates (RSA and ECC, or future PQC certificates), to know which of them are negotiated by clients, as with TLS 1.3, the signature algorithm is no longer part of the $ssl_cipher name.

@ghen2 you're right, it's not part of the $ssl_cipher in TLS 1.3 and we can use ssl_conf_command SignatureAlgorithms xxx or ssl_conf_command ClientSignatureAlgorithms xxx to configure it. It's useful to log the final negociated value for debugging purpose.

@Maryna-f5 Maryna-f5 added this to the nginx-1.29.3 milestone Oct 6, 2025
@pluknet
Copy link
Contributor

pluknet commented Oct 17, 2025

For the server side, I don't see the added value: whoever made a setup is used to know which certificates he is willing to use; that's why there's no similar server-side variables in nginx.

Actually, this can be usable for other purposes, such as logging client-supported scheme(s).
The rest remains.

So, what the change usefully aims to add is ability to obtain the name of the signature used by the client to sign TLS messages. Note that it can be only useful with client certificate validation enabled as this information is served (indirectly) from a passed client certificate. That said, the variable name should be prefixed with "$ssl_client_", similar to other such.

Further, I see a little benefit in using ASN1 object naming, which can be rather cryptic, such as for "id-ecPublicKey". In this regard, IANA names are preferred and would be nice to have instead. This is possible by using SSL_get0_peer_signature_name() introduced in OpenSSL 3.5 specifically for this purpose, i.e. logging.

With these comments applied: #932

@github-actions
Copy link

github-actions bot commented Oct 19, 2025

✅ All required contributors have signed the F5 CLA for this PR. Thank you!
Posted by the CLA Assistant Lite bot.

@willmafh
Copy link
Contributor Author

I have hereby read the F5 CLA and agree to its terms

@willmafh willmafh changed the title SSL: signature variables $ssl_sigalg and $ssl_peer_sigalg SSL: signature variables $ssl_sigalg and $ssl_client_sigalg Oct 21, 2025
@Maryna-f5
Copy link
Contributor

Thank you for the proposal and initial work, @willmafh !
The requested changes have been included in the 1.29.3 mainline release.

@Maryna-f5 Maryna-f5 closed this Oct 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants