| Summary: | Passphrase protected private key in SSLProxyMachineCertificateFile causes SEGV | ||
|---|---|---|---|
| Product: | Apache httpd-2 | Reporter: | kris.verbeeck |
| Component: | mod_ssl | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
| Status: | RESOLVED LATER | ||
| Severity: | enhancement | CC: | apache, erich |
| Priority: | P3 | Keywords: | MassUpdate |
| Version: | 2.0.48 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
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 ? 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. 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 =) 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. I've added a warning about the problem with encrypted keys to the docs. 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. *** Bug 57179 has been marked as a duplicate of this bug. *** 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. |
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)