|Summary:||Passphrase protected private key in SSLProxyMachineCertificateFile causes SEGV|
|Component:||mod_ssl||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
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 Continuing. 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: http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=106629032008685&w=2)
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 password. 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.