вт, 2 дек. 2025 г. в 17:36, Willy Tarreau <[email protected]>: > Hi Ilya, > > On Tue, Dec 02, 2025 at 05:30:18PM +0100, ???? ??????? wrote: > > ??, 2 ???. 2025 ?. ? 17:03, Willy Tarreau <[email protected]>: > > > > > Hi Alexander, > > > > > > On Tue, Dec 02, 2025 at 03:37:40PM +0000, Nicke, Alexander wrote: > > > > Hi, > > > > > > > > We noticed that `ssl_c_r_dn` (the Distinguished Name of the Root CA > of > > > the > > > > Client Certificate) returns empty/null for requests using a resumed > SSL > > > > session, even when the initial handshake used a client certificate > for > > > mTLS > > > > authentication. > > > > > > > > This behavior is somewhat understandable, as the client certificate > > > chain is > > > > not presented again during SSL session resumption. The > implementation in > > > > HAProxy source code acknowledges that the value can be null [1]. > > > However, the > > > > documentation for `ssl_c_r_dn` [2] does not mention this limitation, > > > unlike > > > > `ssl_fc_has_crt` where the exception for SSL resumption is clearly > > > documented > > > > [3]. > > > > > > > > We would like to know whether it is feasible to cache `ssl_c_r_dn` > from > > > the > > > > initial handshake or implement another solution to correctly set this > > > > variable for resumed SSL sessions. We would really appreciate if you > > > looked > > > > into this as some of our usage scenarios rely on the field being set. > > > > > > > > If it is not possible to change this behaviour, I propose to append > the > > > docs > > > > for `ssl_c_r_dn` e.g. with the following: "Note: the field is empty > on > > > SSL > > > > session resumption with Session ID or TLS ticket, even when a client > > > > certificate was provided in the initial handshake of the session". > > > > > > Indeed the doc probably needs to be clarified on this point. It's not > > > possible to cache the info anywhere because the session is nowadays > > > mostly resumed using a ticket which contains everything. So a client > > > can perform the handshake on LB1, get a ticket, and resume on LB2 which > > > anyway will not have the info that could have been cached if we even > had > > > any space for this. > > > > > > I think that we'd need to always think about handshake vs resumption > for > > > all ssl sample fetch methods, at least to make it clear that those who > > > absolutely want to keep such info either are able to store them > somewhere > > > in a 100% identifiable way (e.g. cookie?), or need to disable > resumption > > > (some already do this for low to moderateloads, it's less of a problem > > > nowadays with ECDSA, it just increases reconnection time a bit). But in > > > any case it should be a user's decision based on advices from the doc. > > > > > > > it is identifiable on the "logging" side by logging either session or > > ticket id. > > the first one logged will contain chain as well. > > Sure, but it requires temporal combination. You cannot use that in a > traffic rule to act on a request for example, that's what I meant. If > the info is needed however it might be stored on the client using a > cookie (for HTTP). >
taking into account mtls mentioned, it is some automation (which likely ignores cookies). but yes, passing it to the client side might help. > > Willy >
