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

From: David Timber <dxdt@dev.snart.me>
Date: Feb 21, 2026, 09:16 UTC
Message-ID: <319bf98c-52df-4bf9-b157-e4bc2bf087d6@dev.snart.me>
In-Reply-To: <xmqqh5rbz83b.fsf@gitster.g>

On 2/21/26 01:35, Junio C Hamano wrote:

Show 6 quoted lines

> 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

Show 10 quoted lines

>
> 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.

Show 6 quoted lines

> 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.