Bug 230497 - Apache won't prompt for passphrase for encrypted private keys
Apache won't prompt for passphrase for encrypted private keys
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2007-02-28 19:13 EST by Dax Kelson
Modified: 2008-05-21 12:05 EDT (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2008-0465
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-21 12:05:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2008:0465 normal SHIPPED_LIVE selinux-policy bug fix update 2008-05-20 10:36:31 EDT

  None (edit)
Description Dax Kelson 2007-02-28 19:13:48 EST
Description of problem:
On RHEL5 beta2 (I don't have access to anything newer unfortunately) creating a
SSL cert for Apache with a private key protected by passphrase causes Apache to
fail to start.

# /etc/init.d/httpd start
Starting httpd:                                   [FAILED]

Unencrypting the private key results in Apache being able to start OK.

Older versions of RHEL properly prompted for the passphrase which allowed Apache
to start OK.

I didn't investigate why the passphrase isn't prompted for (SELinux maybe?).
Comment 1 Joe Orton 2007-03-02 08:16:54 EST
Thanks for the report.  This is probably a deliberate tightening of the SELinux
policy, "setsebool httpd_tty_comm 1" will work around it; I'll check though.
Comment 2 Tyler Reese 2007-06-13 17:05:13 EDT
This problem is still appearing in the released version of RHEL 5.  I have a
self-signed cert that I am using on a server for internal testing.  I can start
the server by running /usr/sbin/httpd and it prompts for my pass phase and the
server works fine.

If I try to run the init script I get an non-zero return code and these messages
appear in my /var/log/httpd/ssl_error_log:

[Wed Jun 13 14:27:34 2007] [error] Init: Private key not found
[Wed Jun 13 14:27:34 2007] [error] SSL Library Error: 218710120
error:0D094068:asn1 encoding routines:d2i_ASN1_SET:bad tag
[Wed Jun 13 14:27:34 2007] [error] SSL Library Error: 218529960
error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag
[Wed Jun 13 14:27:34 2007] [error] SSL Library Error: 218595386
error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error
[Wed Jun 13 14:27:34 2007] [error] SSL Library Error: 218734605
error:0D09A00D:asn1 encoding routines:d2i_PrivateKey:ASN1 lib

Which shows its not receiving the pass phrase from stdin because I'm never prompted.

An interesting work around for this bug is when you exec the init.d script if
you run "/bin/bash /etc/init.d/httpd" the prompt appears, you enter your pass
phrase and things work great.

The work around that was given above doesn't work for me.  I get errors from the
init script stating it can't read the crt and key file.  

My best work around for this problem was to just disable SElinux.
Comment 3 Joe Orton 2007-10-24 05:01:32 EDT
Dan, is this a deliberate tightening of the SELinux policy?  In RHEL4 we had
this discussion and in the end the policy shipped did allow tty access.  This
needs to work out of the box.

If we use a separately exec'd process which accesses /dev/tty to read the
password, and talks to httpd via pipes, can the policy allow that?
Comment 4 Daniel Walsh 2007-10-24 09:08:47 EDT
No the policy is supposed to turn on the boolean.  This is a bug.

setsebool -P allow_tty_comm 1

Should fix the boolean setting.

Comment 5 Daniel Walsh 2008-02-26 16:18:57 EST
Fixed in selinux-policy-2.4.6-121.el5
Comment 6 RHEL Product and Program Management 2008-03-05 17:07:34 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 12 errata-xmlrpc 2008-05-21 12:05:09 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.