Need help - Client Authentication

Wall, Stephen stephen.wall at redcom.com
Fri Mar 8 18:28:10 UTC 2024


> From: openssl-users <openssl-users-bounces at openssl.org> 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


More information about the openssl-users mailing list