On 05.01.2014 15:09, Dr Stephen Henson wrote:
> One the subject of 1.0.2 would it be appropriate to set auto ecdh parameter
> selection as the default in mod_ssl where supported? As things stand one
> single
> curve can be set (with default P-256) and it's an all or nothing choice, with
> auto par
On 05/01/2014 09:00, Kaspar Brand wrote:
> On 03.01.2014 23:51, Dr Stephen Henson wrote:
>> On 28/12/2013 13:34, Kaspar Brand wrote:
>>> FYI: in r1553824 (which I just committed to trunk), I'm now manually
>>> shuffling things around to support per-cert chains - but would happily
>>> drop the "#if
On 03.01.2014 23:51, Dr Stephen Henson wrote:
> On 28/12/2013 13:34, Kaspar Brand wrote:
>> FYI: in r1553824 (which I just committed to trunk), I'm now manually
>> shuffling things around to support per-cert chains - but would happily
>> drop the "#if defined(SSL_CTX_set1_chain)"-enclosed code if y
On 28/12/2013 13:34, Kaspar Brand wrote:
> On 18.11.2013 18:42, Kaspar Brand wrote:
>> On 18.11.2013 15:38, Dr Stephen Henson wrote:
>>> For OpenSSL 1.0.2 this limitation is removed and you can have different
>>> chains
>>> for each certificate type (and for SSL structures too) and it just uses th
On 18.11.2013 18:42, Kaspar Brand wrote:
> On 18.11.2013 15:38, Dr Stephen Henson wrote:
>> For OpenSSL 1.0.2 this limitation is removed and you can have different
>> chains
>> for each certificate type (and for SSL structures too) and it just uses the
>> right one. This uses the function SSL_CTX_
On 06.12.2013 01:17, Daniel Ruggeri wrote:
> On 11/14/2013 5:54 AM, Joe Orton wrote:
>> a) people who want the ability to do filesystem backups without exposing
>> private keys to the set of admins who can read such backups; or e.g.
>> stick keys on NFS mounts, a similar requirement there.
>>
>>
On 12/5/2013 6:17 PM, Daniel Ruggeri wrote:
> On 11/14/2013 5:54 AM, Joe Orton wrote:
>> a) people who want the ability to do filesystem backups without exposing
>> private keys to the set of admins who can read such backups; or e.g.
>> stick keys on NFS mounts, a similar requirement there.
>>
>>
On 11/14/2013 5:54 AM, Joe Orton wrote:
> a) people who want the ability to do filesystem backups without exposing
> private keys to the set of admins who can read such backups; or e.g.
> stick keys on NFS mounts, a similar requirement there.
>
> b) people who like or are required to follow "secu
On 18.11.2013 15:38, Dr Stephen Henson wrote:
> Erk typo.. I of course meant "...after you call SSL_CTX_use_certificate_file
> or
> SSL_CTX_use_certificate_chain_file..."
Yeah this was obvious... makes me cringe as well but here we go:
https://people.apache.org/~kbrand/mod_ssl_pkey_2013-11-18_
On 17/11/2013 15:25, Dr Stephen Henson wrote:
>
> Evil hack workaround: create a temporary SSL structure from the SSL_CTX of
> interest after you call SSL_CTX_get_certificate, call SSL_get_certificate on
> it
> and then free up the temp SSL structure. That *should* work on all the
> versions
> o
On 17/11/2013 15:01, Kaspar Brand wrote:
>
> One issue I'm facing with the current implementation is that when
> relying on SSL_CTX_use_certificate_file/
> SSL_CTX_use_certificate_chain_file to configure the cert, there's no way
> to get at the X509 * which really got configured for the SSL_CTX
>
On 17.11.2013 15:43, Dr Stephen Henson wrote:
> On 13/11/2013 14:06, Kaspar Brand wrote:
>>
>> - only supporting unencrypted private keys with "SSLOpenSSLConfCmd
>> PrivateKey ..."
>>
>
> Just to clarify that. Do you mean that SSLOpenSSLConfCmd shouldn't work with
> encrypted private keys at all
On 14.11.2013 12:54, Joe Orton wrote:
> I've also always been a sceptic of this (mis)feature, so I hate to be
> one to defend it. But demand comes from:
>
> a) people who want the ability to do filesystem backups without exposing
> private keys to the set of admins who can read such backups; or
On 13/11/2013 14:06, Kaspar Brand wrote:
>
> I'm not proposing to drop support for encrypted private keys from 2.4.x
> (yet), to be clear - I guess we need to keep this for quite some while
> for backwards compatibility. I suggest, however, to only support
> unencrypted private keys with the "SSLO
On Thu, Nov 14, 2013 at 07:02:58AM +0100, Kaspar Brand wrote:
> On 13.11.2013 15:28, Dr Stephen Henson wrote:
> > I can vaguely recall that some of that code is designed to avoid the need to
> > enter the private key passphrase more than once by decrypting private keys
> > once
> > and storing the
On 13.11.2013 15:28, Dr Stephen Henson wrote:
> I can vaguely recall that some of that code is designed to avoid the need to
> enter the private key passphrase more than once by decrypting private keys
> once
> and storing the unencrypted forms in serialised form.
True, it allows to SIGHUP/SIGUSR
On 13/11/2013 14:06, Kaspar Brand wrote:
>
> Taking a step back, however, I wonder what problem we're really solving
> with the support for encrypted private keys. SSLPassPhraseDialog and its
> three incarnations (builtin, pipe and exec) have been in mod_ssl ever
> since 2.0, sure, but what do the
On 23.10.2013 16:09, Kaspar Brand wrote:
> On 21.10.2013 06:09, Trevor Perrin wrote:
>> I looked at your patch. Besides lack of passphrase-handling, it
>> breaks compatibility with existing config files (which assume
>> certs/keys are matched by type, not order).
>
> I don't think that "random or
18 matches
Mail list logo
