Bug 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
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.0.40
Hardware: Other Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2004-06-10 14:11 UTC by Kris Leclair
Modified: 2004-11-16 19:05 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Kris Leclair 2004-06-10 14:11:08 UTC
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 
- 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 
Comment 1 Joe Orton 2004-06-10 15:09:00 UTC
Probably bug 21160.  If you have the final httpd update issued for RHL9
(2.0.40-21.11), you should have the fix for this.

*** This bug has been marked as a duplicate of 21160 ***
Comment 2 Cliff Woolley 2004-06-10 18:37:53 UTC
I don't think this is actually a dupe of that bug.  I'm reopening it, however, 
only so I can mark it as RESOLVED/WONTFIX.  The reason you cannot pick up a 
changed encrypted private key by doing a graceful restart is that the process 
of entering the password requires Apache to still be attached to the terminal, 
which it is not over the course of a graceful restart.  If you want to change 
private keys, do a full stop/start. 
Comment 3 Cliff Woolley 2004-06-10 20:55:54 UTC
See email thread that follows.  I still say this isn't "expected" to work at 
all, but this at least sounds like mildly curious behavior. 
Comment 4 Cliff Woolley 2004-06-10 20:56:17 UTC
> I'm a little confused about the expected behaviour of a graceful restart. 
> The fact is that a graceful restart often does correctly pick up the new 
> encrypted keyfile and either correctly query for the password or get the 
> password from a script. Why does this work under some circumstances and 
> others? 
I thought you said it always worked if the keyfile was not encrypted but 
did not work if the keyfile was encrypted.  Is that not the case? 
If it works at all, then it's news to me... back in the mod_ssl for Apache 
1.3 days, it was guaranteed not to work.  :-) 
Comment 5 Cliff Woolley 2004-06-10 20:56:41 UTC
From: Kristianne Leclair <kleclair@magma.ca> 
To: 'Cliff Woolley' <jwoolley@apache.org> 
Subject: RE: [Bug 29496]  -     New keyfile isn't always picked up when 
    graceful restart is used 
Hi Cliff, 
Thanks, I'm sorry, if my description was not clear. The behaviour you 
describe below is exactly the behaviour I had observed in 1.3 - in fact for 
1.3 I found that you had to stop and start the server to pick up an updated 
keyfile regardless of whether it was encrypted or not. 
What I've found for 2.0 is as follows: 
- if all keyfiles on the server are unencrypted a new keyfile is always 
picked up on graceful restart 
- if the server only has a single virtual host - a new encrypted keyfile 
seems to be picked up correctly on graceful restart 
- if the server has multiple virtual hosts with at least one of the servers 
using an encrypted keyfile, an update to any other keyfile may or may not be 
picked up correctly on graceful restart 
It is this last case that I'd tried to describe in my submission. The thing 
is that this behaviour seems to be slightly unpredictable. For example if 
you have 3 virtual hosts all with encrypted keyfiles, updating the keyflile 
for the second host and restarting with graceful may be fine. It seems to 
fail most commonly when the updated keyfile is for the first listed virtual 
host. I've also found that if you try restarting gracefully multiple times 
it may eventually recognize the change and ask you for the password. 
Any insights? 
Comment 6 Joe Orton 2004-06-10 21:50:49 UTC
The behaviour hasn't changed since 1.3: mod_ssl cannot decrypt new or changed
encrypted private keys on a graceful restart, since it neither caches any
passwords over restart, nor can prompt for it at restart.  mod_ssl will continue
using an unchanged encrypted over a restart, and can load new or changed
unencrypted private keys too.  That is a WONTFIX bug as Cliff says.

You describe being prompted for a password during a graceful restart: if that
happens, what's really happening is something like:

1) first "apachectl graceful" fails due to new private keys and *stops the server*
2) second "apachectl graceful" notices the server is stopped and starts a new
one, prompting for the private keys

So maybe you want to retest given that fact.  If you do have a server which is
afflicted with bug 21160, Random Stuff may happen with >1 encrypted private key,
all bets are off.
Comment 7 Joe Orton 2004-09-22 11:39:31 UTC
Closing presuming the problem was as I outlined above: otherwise, we need a
reproduction case for a genuine failure.