search

benluteijn / cherokee

Automatically exported from code.google.com/p/cherokee
0 stars 1 forks source link

Graceful restart without new SSL opening #222

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. http://code.google.com/p/cherokee/issues/detail?id=179

What is the expected output? What do you see instead?
It would be nice if we could do a graceful restart, without reopening the
certificates. So, a user would just be able to use the webserver...

Original issue reported on code.google.com by ste...@konink.de on 14 Nov 2008 at 1:14

GoogleCodeExporter commented 9 years ago 
If I had to change the certificate of one of the virtual servers, I'd most 
probably use 'Graceful Restart' after I either 
changed the file or the configuration.

This RFE doesn't make much sense to me. Stefan, could you please elaborate on 
the rational behind the request? 
:-?

Original comment by alobbs on 17 Nov 2008 at 9:13

GoogleCodeExporter commented 9 years ago 
Because any graceful restart now will just kill the server and start a new 
instance,
hence ask for the PEM key of the certificate again (at the console) thus it is 
no
graceful restart, it actually kills the non HTTPS instance too.

Original comment by ste...@konink.de on 17 Nov 2008 at 9:15

GoogleCodeExporter commented 9 years ago 
Yeah, it would be a problem, actually. However, I don't know what the best 
solution would be.
While reloading the certificate is desirable, re-entering the password is not.. 
and that's actually a problem.

I'm not sure whether we'll be able to fix this issue without implementing some 
sort of mechanism with which 
cherokee-admin could ask for the certificate password.

Ideas?

Original comment by alobbs on 17 Nov 2008 at 9:41

GoogleCodeExporter commented 9 years ago 
Firstly the http part should *always* be started. It should not block on the 
HTTPS
part. Secondly I think the PEM part is process specific; now I don't want to you
reimplement the cherokee reloading completely because I understand how it works.

I wonder; this could get into real issues btw; imagine what happens if a https
capable worker is restarted due to a problem. It would block the entire server. 
It
might be good to give the parent process the certificate.

Original comment by ste...@konink.de on 17 Nov 2008 at 9:50

GoogleCodeExporter commented 9 years ago 
Yeah, that makes sense.  Cherokee could store the passwords and pass them to 
cherokee-work each time it's 
restarted.

I'm not sure about the technical side, though. What would be the way of reading 
and passing the passwords of 
multiple certificates? It sounds kinda messy to me. :-m

Original comment by alobbs on 17 Nov 2008 at 10:10

GoogleCodeExporter commented 9 years ago 
If you want to mark Cherokee as security leak where it is possible to read out
passwords from memory. I wouldn't take that approach ;)

But storing the *actual* extracted certificates. Sounds reasonable? Since that
happens always anyhow.

Original comment by ste...@konink.de on 17 Nov 2008 at 10:21

GoogleCodeExporter commented 9 years ago 
I would just suggest to take the easy approach and use passwordless root-only 
certs.
Closing this bug.

Original comment by ste...@konink.de on 10 Dec 2008 at 10:16