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 release.
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. http://rhn.redhat.com/errata/RHBA-2008-0465.html