httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaspar Brand <>
Subject Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl?
Date Sun, 17 Nov 2013 15:01:19 GMT
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 e.g. 
> stick keys on NFS mounts, a similar requirement there.

Hmm ok, these can be considered (IMO somewhat contrived) use cases,
though I think it's possible to suggest workarounds should we decide to
completely drop support for encrypted private keys (e.g. exclude the
unencrypted key from the backup, and store an encrypted one in parallel
/ decrypt the encrypted files to a RAM disk and let httpd load them from
there and similar).

Let me note that that "other" popular open-source HTTP server doesn't
have any useful support for encrypted private keys... it will just pop
up OpenSSL's default "Enter PEM pass phrase:" prompt (once for each
ssl_certificate_key directive, with a single chance of entering the
correct pass phrase for each), and on receiving SIGHUP will simply abort
the config reload. IOW, lack of support for encrypted private keys does
not seem like a "must have" feature for an HTTP server these days.

> b) people who like or are required to follow "security by checklist" or 
> "security by regulator"; some auditor has "No Plaintext Keys !!!" on the 
> checklist, and so we must not use plaintext keys, no argument.

Oh yes these auditors I like in particular. Probably the same ones who
think that not ticking the "Mark this key as exportable" option when
importing a key into the Windows cert store does indeed prevent people
from extracting them (see
for evidence to the contrary).

> I'm most sceptical of all about (b) as motivation for increasing 
> software complexity, but (a) I can at least appreciate.

Does this mean you would object to the eventual removal of support for
encrypted private key files in mod_ssl?

To get a step further, I put a snapshot of my WIP patch for lifting the
"no more than 3 certs/keys" limit with ssl_pphrase_Handle etc. under

It includes a fairly large number of changes (which I would most likely
split into smaller pieces when committing to trunk), but my hope is that
other people could give it a try and provide feedback. Brief list of
notable changes:

- do not index keys by algorithm (use a simple int index)

- repurpose ssl_pphrase_Handle as ssl_load_encrypted_pkey (and
  only use when needed, i.e. when encountering an encrypted key)

- change the prompt for the "builtin" dialog to also show the
  filename (but drop the algorithm type, also for the "exec" dialog)

- remove the "myCtxVarGet abomination" (replace with a pphrase_cb_arg_t
  struct, which currently keeps most of the existing variable names,
  for the sake of better comparability with the previous code)

- move the SSL_CONF_cmd invocations after the ssl_init_server_cert
  call, so that it can be used as either a complement of
  the SSLCertificate[Key]File directives, or as a substitute
  (when including "PrivateKey" and "Certificate" commands)

- drop SSL_read_X509 from ssl_util_ssl.c (no longer needed)

- remove SGC related bits (SGC has been dead for years)

- drop the code for supporting SSLPKCS7CertificateFile (was never
  documented, either SSLCertificateChainFile and/or SSLCertificateFile
  serve the same purpose, and a PKCS#7 file can be trivially converted
  into a file for use with SSLCertificateChainFile)

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
(remember that we're compiling with OPENSSL_NO_SSL_INTERN for OpenSSL
1.0.0 or later).

Steve, could you consider adding SSL_CTX_get_certificate, which would
allow retrieving the "current cert" (i.e. one set by the last
SSL_CTX_use_certificate* call)? And perhaps SSL_CTX_get_privatekey as
its companion, at the same time? Without SSL_CTX_get_certificate at
least, we can't call ssl_stapling_init_cert, unfortunately.

Feedback would be much appreciated (in particular from people who rely
on encrypted keys and could give the patch a try with their existing


View raw message