Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 230497 - Apache won't prompt for passphrase for encrypted private keys
Summary: Apache won't prompt for passphrase for encrypted private keys
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Daniel Walsh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-03-01 00:13 UTC by Dax Kelson
Modified: 2008-05-21 16:05 UTC (History)
2 users (show)

Fixed In Version: RHBA-2008-0465
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-05-21 16:05:09 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2008:0465 normal SHIPPED_LIVE selinux-policy bug fix update 2008-05-20 14:36:31 UTC

Description Dax Kelson 2007-03-01 00:13:48 UTC
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 13:16:54 UTC
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 21:05:13 UTC
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 09:01:32 UTC
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 13:08:47 UTC
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 21:18:57 UTC
Fixed in selinux-policy-2.4.6-121.el5

Comment 6 RHEL Product and Program Management 2008-03-05 22:07:34 UTC
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 16:05:09 UTC
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.