Re: [PATCH v1 1/1] send-mail: add client certificate options

[David Timber <dxdt@dev.snart.me>]

On 2/21/26 01:35, Junio C Hamano wrote:
> This makes me wonder what the use case is for giving separate key
> file with a certificate file with its own private key in it.  The
> documentation above clearly describes what happens (i.e., the
> separate key file makes the key embedded in the certificate file
> ignored), but I cannot quite think of a reason why anybody would
> want to do so. 
I know. The design of the Perl SSL interface is not top notch.

https://metacpan.org/dist/IO-Socket-SSL/view/lib/IO/Socket/SSL.pod
>
> For each certificate a key is need, which can either be given as a
> file with SSL_key_file or as an internal representation of an
> EVP_PKEY* object with SSL_key (like you get from Net::SSLeay or
> IO::Socket::SSL::Utils::PEM_xxx2key). If a key was already given
> within the PKCS#12 file specified by SSL_cert_file it will ignore any
> SSL_key or SSL_key_file. If no SSL_key or SSL_key_file was given it
> will try to use the PEM file given with SSL_cert_file again, maybe it
> contains the key too.
>
To summarise:

  * PKCS12: the key in the cert always takes the precedence
  * PEM: if the key file is not given, it will "try" to read one from
    the cert PEM file

I don't know why anyone would want to put the cert and the key in the
same file, not even openssl impose that, but somehow, somewhere, there
are people who do and Perl had to cater for the kind as it seems.

> The key in the separate file is still something that
> corresponds to the public part in the certificate, no?  The certificate
> can say "The subject of the certificate may use a private key that
> corresponds to any of these three public keys", and the certificate
> file may only have one or two but not all of these three public
> keys, or something?
I think this is why they made the logic that way (at least for PKCS12)
to prevent the exact madness you were describing. Still, I'd agree that
the asymmetry is horrendous.

I'm just trying to expose what's possible with the Perl SSL interface to
the user as much as possible. Paranoid people(like me who would want to
set up mtual vertification to deter bot attacks) would want both PEM and
PKCS12 because major implementations including Thunderbird and K-9 only
accept PKCS#12(imposed by the application and imposed by the operating
system - Android, respectively) while the openssl x509 stack is more
suited for PEM(separate cert and key).

It's a niche, I know. But something tells me that you'd want to push
this feature forward. Thank you for the rest of the comments. Will come
back with the revised patch that I hope may unconfuse you. Good to know
the project is in good hands.