вт, 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. > > Regards, > Willy > > >
