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