DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=29496>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29496 New keyfile isn't always picked up when graceful restart is used Summary: New keyfile isn't always picked up when graceful restart is used Product: Apache httpd-2.0 Version: 2.0.40 Platform: Other OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Runtime Config AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] Overview Description: I have found that the server does not always pick up an updated keyfile / certificate when a graceful restart is used. This seems to only occur when one or more of the keyfiles used by virtual hosts are password protected. Steps to Reproduce: The scenario I have tested is as follows: - an Apache 2.0.40 server on RedHat Linux 9 with several virtual hosts configured - each host has a password protected keyfile using the same password - the SSLPassPhraseDialog may be set to builtin or pointing to a script - either case results in the same behaviour - update the key and certificate for one of the servers - preferably the default virtual host or the first listed virtual host - restart the server using 'apachectl graceful' Actual Results: The server restarts but does not read the new keyfile and does not prompt for any keyfile passwords. In order to pick up the new keyfile a stop and start must be used Expected Results: The server should pick up an updated, password protected, keyfile / certificate on graceful restart as well as for stop and start. Additional Notes: Note that I have found that this behaviour is not 100% consistent. It seems that multiple virtual hosts are required with at least one of the hosts having a password protected keyfile. It seems to happen with the greatest frequency for the first vitual host listed in the conf file. This does not seem to be a problem if none of the keyfiles are password protected. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
