Bug 24031 - Passphrase protected private key in SSLProxyMachineCertificateFile causes SEGV
Summary: Passphrase protected private key in SSLProxyMachineCertificateFile causes SEGV
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.0.48
Hardware: All All
: P3 enhancement with 3 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: MassUpdate
: 57179 (view as bug list)
Depends on:
Reported: 2003-10-23 06:37 UTC by kris.verbeeck
Modified: 2018-11-07 21:08 UTC (History)
2 users (show)


Note You need to log in before you can comment on or make changes to this bug.
Description kris.verbeeck 2003-10-23 06:37:33 UTC
The current reverse proxy code can not handle private keys that are
passphrase protected.  The key is never decrypted (there is no
passphrase prompt) which results in a SIGSEGV.  Using a non-encrypted
key fixes this SIGSEGV.

GDB info of the segfault (no backtrace available):

   (gdb) c
   Program received signal SIGSEGV, Segmentation fault.
   0x0810d39c in X509_check_private_key (x=0x8236b30, k=0x82420a8)
       at x509_cmp.c:380
   380                     if (BN_cmp(xk->pkey.rsa->n,k->pkey.rsa->n) != 0

(See also the following thread:
Comment 1 Matthieu Estrade 2003-11-13 21:48:59 UTC
Is it possible to ask the passphrase and to control the private key at apache 
startup, or does it just not use the certificate is private key is not ok ?

Comment 2 kris.verbeeck 2003-11-14 07:29:40 UTC
Yes I think the solution should be to ask for the passphrase at Apache startup
(in the a similar way as it is done for the mod_ssl server keys).  As for the
second part of your question, Apache (the SSL proxy code) tries to use the
certificate to do client authentiation, but when it gets to the phase where it
should use the (decrypted) private key the SEGV occurs because there is no
decrypted version of that private key.  I traced trough the code and the actual
X509 object that is being used, does contain the correct client certificate and
encrypted private key.
Comment 3 Matthieu Estrade 2003-11-14 10:03:58 UTC
What i found in the code is all x509 clients  certificates are read with: 
SSL_X509_INFO_load_file function,
which is  modssl_PEM_X509_INFO_read_bio
which is:

crypto/pem/pem.h:STACK_OF(X509_INFO) *  PEM_X509_INFO_read_bio(BIO *bp,
STACK_OF(X509_INFO) *sk, pem_password_cb *cb, void *u);

Seems ssl module does not use pem_password callback to eventually take the password:
modssl_PEM_X509_INFO_read_bio(in, sk, NULL, NULL);

i will continue in this way and find how i could do to ask the pem password.
Even if the private key need a passphrase and it's maybe different than the pem

Tell me if you see i am directly going into a wall =)
Comment 4 Joe Orton 2003-11-25 21:20:49 UTC
Matthieu, the way this would need to be done is to extend the existing code in
ssl_engine_pphrase.c so that it can decode any encrypted private keys for the
proxy config structures at the right time during startup, not sure if you'd
worked this much out already.
Comment 5 Mads Toftum 2004-01-05 22:15:19 UTC
I've added a warning about the problem with encrypted keys to the docs.
Comment 6 Joe Orton 2004-01-26 22:35:27 UTC
This bug tracks the feature request to add support for encrypted private keys to
the SSL proxy code.  The SEGV is fixed per bug 24030.
Comment 7 Kaspar Brand 2014-11-05 09:29:47 UTC
*** Bug 57179 has been marked as a duplicate of this bug. ***
Comment 8 William A. Rowe Jr. 2018-11-07 21:08:54 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.