Skip Menu |

This queue is for tickets about the IO-Socket-SSL CPAN distribution.

Report information
The Basics
Id: 82761
Status: resolved
Priority: 0/
Queue: IO-Socket-SSL

Owner: Nobody in particular
Requestors: karel.miko [...]

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

From karel.miko [...] Wed Jan 16 13: 52:01 2013
MIME-Version: 1.0
X-Spam-Status: No, score=-5.219 tagged_above=-99.9 required=10 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_NEUTRAL=0.779] autolearn=ham
X-Spam-Flag: NO
Content-Type: multipart/mixed; boundary="------------010701020201010803010606"
Message-ID: <50F6F6C3.6020303 [...]>
X-Virus-Scanned: Debian amavisd-new at
X-Spam-Score: -5.219
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0B922404CD for <cpan-bug+io-socket-ssl [...]>; Wed, 16 Jan 2013 13:52:00 -0500 (EST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LVzpuWImVuT6 for <cpan-bug+io-socket-ssl [...]>; Wed, 16 Jan 2013 13:51:59 -0500 (EST)
Received: from ( []) by (Postfix) with SMTP id DA04B2400EC for <bug-io-socket-ssl [...]>; Wed, 16 Jan 2013 13:51:58 -0500 (EST)
Received: (qmail 30211 invoked by uid 103); 16 Jan 2013 18:51:58 -0000
Received: from ( by with QMQP; 16 Jan 2013 18:51:58 -0000
Received: from (HELO ( by (qpsmtpd/0.84/v0.84-167-g4ed6cab) with ESMTP; Wed, 16 Jan 2013 10:51:54 -0800
Received: from ([]) by (InterMail vM. 201-2260-151-110-20120111) with ESMTP id < [...]> for <bug-io-socket-ssl [...]>; Wed, 16 Jan 2013 19:51:49 +0100
Received: from [] ([]) by with edge id oirn1k00T4z0HsE04irnc5; Wed, 16 Jan 2013 19:51:49 +0100
Delivered-To: cpan-bug+io-socket-ssl [...]
Subject: Server side SNI support
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
Return-Path: <karel.miko [...]>
X-RT-Mail-Extension: io-socket-ssl
X-Original-To: cpan-bug+io-socket-ssl [...]
Date: Wed, 16 Jan 2013 19:51:47 +0100
To: bug-IO-Socket-SSL [...]
From: Karel Miko <karel.miko [...]>
Content-Length: 0
content-type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-RT-Original-Encoding: windows-1250
Content-Length: 613
Download (untitled) / with headers
text/plain 613b
Hi, Net::SSLeay has server side SNI support since 1.50 Please find enclosed proposal for adding server side SNI also to IO::Socket::SSL. It is implemented via a new option: SSL_server_SNI => { '' => ['h1.crt', 'h1.key'], '' => ['h2.crt', 'h2.key'] } or SSL_server_SNI => sub { my $host = shift; ...; return ($certfile, $keyfile) }, If you find my proposal handy I can write a piece of documentation for this new feature. Regards -- Karel
content-type: text/plain; charset="utf-8"; name="Server_SNI_support.diff"
content-disposition: attachment; filename="Server_SNI_support.diff"
Content-Transfer-Encoding: 7bit
X-RT-Original-Encoding: windows-1250
Content-Length: 2260

Message body is not shown because sender requested not to inline it.

MIME-Version: 1.0
In-Reply-To: <50F6F6C3.6020303 [...]>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <50F6F6C3.6020303 [...]>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-32003-1359919215-1761.82761-0-0 [...]>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 975
Download (untitled) / with headers
text/plain 975b
Show quoted text
> > Please find enclosed proposal for adding server side SNI also to > IO::Socket::SSL.
Hi Karel, thanks for the patch. Although I implemented it in a different way, I was inspired by your patch and motivated, that someone needs this feature. The main difference to your patch is, that I did not add a new option, but instead let SSL_key* and SSL_cert* use a hash reference to provide the mapping between hostname and key/cert. The creation of the context per host is then done at configure time, and not when a client connects. I liked this approach more, because you get any problems with the keys or cert reported earlier. Also, not only cert and key files are supported, but also cert and key values (e.g. X509* and PKEY* objects). The drawback of this approach is, that I don't offer a callback function, which determines cert and key when the client connects. This might be added in the future, but currently I don't see much value in it. Thanks again, Steffen

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to