Red Hat Bugzilla – Bug 230497
Apache won't prompt for passphrase for encrypted private keys
Last modified: 2008-05-21 12:05:09 EDT
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?).
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.
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.
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?
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.
Fixed in selinux-policy-2.4.6-121.el5
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
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.