On 02/10/2013 08:35, Kaspar Brand wrote:
> On 01.10.2013 12:15, Dr Stephen Henson wrote:
>> That's just OpenSSL internals though. To handle ServerInfo properly in 
>> mod_ssl
>> IMHO you would need a new directive as there's no support for per-certificate
>> SSL_CONF commands: it wasn't intended to be used like that in its current 
>> form.
>>
>> This also runs against what IMHO is a long standing historical problem with 
>> the
>> way mod_ssl handles certificates: it hard codes the algorithms used in the
>> source. That means every new algorithm needs mod_ssl code changes to support:
>> ECC for example.
> 
> True. I guess it's a side effect of keeping private key pass phrases in
> the global SSLModConfigRec. From ssl_private.h:
> 
>> /* BIG FAT WARNING: SSLModConfigRec has unusual memory lifetime: it is
>>  * allocated out of the "process" pool and only a single such
>>  * structure is created and used for the lifetime of the process.
> [...]
>>  * This odd lifetime strategy is used so that encrypted private keys
>>  * can be decrypted once at startup and continue to be used across
>>  * subsequent server reloads where the interactive password prompt is
>>  * not possible.
> [...]
>>  * This should really be fixed using a smaller structure which only
>>  * stores that which is absolutely necessary (the private keys, maybe
>>  * the random seed), and have that structure be strictly ABI-versioned
>>  * for safety.
> 
> Whether the latter is doable without breaking backward config
> compatibility (in particular for the SSLCertificate*File directives)
> needs further examination, I guess.
> 

I'd be interested in seeing what can be done to address this. One problem I
noticed in the past is that the serialisation of keys in Apache is not algorithm
independent: you can get around that by using PKCS#8 which is supported in all
the versions of OpenSSL of interest.

Well it works for software keys. For HSM keys there are some rather thorny
issues which are trickier to handle. I don't think those are currently 
supported?

Are you (or is anyone else) aware of any limitations on the OpenSSL side that
prevent revision of the code to support arbitrary numbers of certificates in an
algorithm independent way?

There's one (relatively minor) one I can think of. If you set another
certificate of the same type OpenSSL silently overwrites the old one. That means
you can't currently catch configuration errors: e.g. trying to use two
certificates of the same type.

Steve.
-- 
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com

Reply via email to