Hi Stephen,
Thank you very much for the help.
Thanks
Jason
On Fri, Mar 8, 2024 at 1:28 PM Wall, Stephen <stephen.wall@xxxxxxxxxx> wrote:
> 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
