On 02/06/2014 12:35 AM, Kaspar Brand wrote: > On 05.02.2014 18:13, Falco Schwarz wrote: >> Kaspar, I ran into another issue when using an encrypted private key and >> "SSLOpenSSLConfCmd PrivateKey". >> Again it fails to load the encrypted private key with the following errors: > > That's by design, see [1]. Eventually I'd like to drop support for > encrypted private keys from trunk.
As part of the goal of dropping encrypted private key support, have you
considered using an agent-based framework for private keys?
As a point of reference, OpenSSH added agent-based host key support for
sshd on 2013-07-20.
tTe basic model is:
0) there is a running agent that holds secret key material and listens
on a socket (unix-domain sockets are nice because of the possibility of
tight filesystem permission control)
1) the daemon (httpd, sshd) knows how to talk to the agent, to request
a list of available keys, and to request signing or decryption
operations to be done by the keys.
2) the agent has a set of rules that govern when and how to obey a
specific request for signing or decryption operations
3) the sysadmin has an interface to load password-protected keys into
the agent.
You can also run the agent under a different user account than the web
server, so that a runaway web server process wouldn't have access to the
secret key material without some other privilege escalation. And you
can commit to a very small-footprint agent, with less room for bugs and
exploits, as compared to the entire modular webserver.
PKCS#11 is one formalization of this approach (though i think that PKCS
#11's shared object interface itself is pretty problematic in today's
multi-core/multi-threaded/multi-process architectures).
Anyway, with some sort of agent-based approach, you could preserve
encrypted keys-on-disk (for Joe Orton's examples of admins with access
to full-machine backups, or secret-keys-on-NFS) while leaving apache
agnostic about the way the keys get *into* the agent.
--dkg
signature.asc
Description: OpenPGP digital signature
