Description of problem:
Since upgrading to Apache 2.0.4x from 1.3.x, I am no longer able to enter the
PEM pass phrase during the boot process. Since I can sshd at that point, I can
see that the process has started and that it has sent the login prompt
*somewhere*, just not where it should be. I was told by Apache that I should
report the bug to you. Here are the symptoms.
1. It DOES prompt for the PEM passphrase once the system is fully loaded and I
am logged into the bash shell either at the console or via an SSH session.
2. It DOES NOT prompt for the passphrase during startup at console where it
used to on 1.3.x. It goes through all the motions, and displays "Starting
httpd.....", but the passphrase prompt does not appear as it should. Ignoring
its absence, typing the PEM passphrase and sending a carriage return does not
fix it. The machine simply does not continue to boot, as there is never
a "succeeded" for httpd in the boot script display. My guess is that whatever
is generating the script is not directing it to prompt for the PEM passphrase
Note: This has been replicated on several different Dell PowerEdge servers
(just in case hardware is somehow an issue?) on RedHat Enterprise Linux WS
2.1, RedHat 7.3, and RedHat 9.0.
Version-Release number of selected component (if applicable):
httpd 2.0.47 (source installation)
Steps to Reproduce:
1. Install httpd 2.0.4x from source with mod_ssl support:
2. Set up the private key to require the PEM passphrase.
3. Use the private key to generate a cert request and install an SSL cert.
5. Try to get past the "Starting httpd..." screen on the console.
Boot process gets stuck while trying to start httpd. No PEM passphrase prompt
I should be prompted for the PEM passphrase at the console.
Am using RPM of openssl.
Can you reproduce this using the httpd-2.0.40 package included in Red Hat Linux 9?
If you are using a self-compiled httpd from a source tarball, the bug at
apache.org was the appropriate place to report it.
I can't reproduce this in the 2.0.46-based packages included in RHEL3.
2.0 is not supported by Red Hat on RHEL2.1, so this bug is not valid