search

noxxi / p5-io-socket-ssl

IO::Socket::SSL Perl Module
36 stars 60 forks source link

Feature request: SSL_cert_file/key_file hash ref for client connections #65

Closed stolendata closed 7 years ago

stolendata commented 7 years ago

We're indirectly using your module as part of an application doing large-scale push notifications. Sometimes an endpoint requires a client certificate which we accommodate through SSL_ca_file/cert_file/key_file, but during client connections - unlike the server scenario - the forementioned parameters will only accept string scalars holding a single file, forcing us to create multiple objects in the overlying module making use of IO::Socket::SSL, instead of being able to hand out a common hash ref mapping all of the certs/keys.

It would be useful if IO::Socket::SSL could trawl hash refs with host=>file mappings for SSL_ca_file/cert_file/key_file also in the case of client connections, just as it does for a server scenario.

noxxi commented 7 years ago

If I understand you correctly you expect a feature to choose the client certificate based on the name on the target server. I don't think that this should be done inside IO::Socket::SSL since it can be easily done outside when creating the SSL socket, i.e. 

my %certs = ( target1 => [ 'foo.pem', 'foo.key'], target2 => ... );
IO::Socket::SSL->new(
   PeerAddr => $servername,
   SSL_cert_file => $certs{$servername}[0],
   SSL_key_file => $certs{$servername}[1],
   ...
)

... forcing us to create multiple objects in the overlying module making use of IO::Socket::SSL, instead of being able to hand out a common hash ref mapping all of the certs/keys.

If the code in question does not allow you to give your own arguments to IO::Socket::SSL you can still use set_args_filter_hack to slip your own settings in.

... unlike the server scenario

The server scenario is different. While in the client scenario the hostname and thus the certificate to choose is known up-front before creating the SSL connection, these information are only available at the server side after the initial ClientHello since the client specifies the expected hostname in the SNI TLS extension. Thus it is unknown when creating the SSL socket which of the specified certificates will actually be used.