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). Willy
