> From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of > Viktor Dukhovni > > On Fri, Mar 08, 2024 at 03:50:31PM +0000, Wall, Stephen wrote: > > So, no. The callback would be used when the client certificate is > > encrypted and needs a password. > > No. The client certificate (received from the remote client as part of the TLS > handshake) is never encrypted with a password (in TLS 1.3 the enclosing TLS > record will be encrypted with a key derived from the exchanged key share > messages). Thanks for the correction. My statement above should have read "when the client certificate's private key is encrypted", and is referring to the client end of the connection. I keep my certificates and private keys in the same file, so typically only need to specify the certificate in configuration files. Note that I was not referring to the certificate sent over the wire, rather the cert/key file on the filesystem. If a program needs to provide a certificate from the filesystem as part of the TLS handshake, then it also needs to access the private key for that certificate. If that private key is encrypted, then a password is needed. That applies to both clients and servers. These functions allow you to provide an alternate way for the client/server software to get the password (default is typically to prompt for it), for example, query a database, return a fixed or calculated string, open a GUI dialog. I'll also note that per their man pages, the "PEM_read_*()" functions will interpret their callback data parameter as a null-terminated string containing the password *if* the callback function parameter is NULL (new info to me), so using only "SSL_CTX_set_default_passwd_cb_userdata()" to set a static password string might be viable. I have not tested that or seen code that does this. -spw
