Christoph Biedl <ngircd.anoy(a)manchmal.in-ulm.de> wrote:
Florian Westphal wrote...
I had code which did load the new
certificates/keys in the OpenSSL backend,
but if memory serves me right I didn't find a simple way to do the same
with gnutls... so i removed the reload-feature completely.
I see.
"Why would anyone have to re-generate
certificates/keys on-the-fly anyway?"
8-(
Are you asking the gnutls guys or me? If the latter: Certificates tend
to expire every now and then
Right, i did not consider this.
And restarting an ircd is always a harsh
operation, but how about implementing the /upgrade feature as seen in
irssi? ;->
Heh. I'd rather not ;-)
But you're right, it should be possible to re-load both keys
and certificates.
> I'll go through my archive and will re-add
the reload feature to
> the OpenSSL backend and look at the gnutls stuff again.
I remember why i changed this.
Previously, the ngircd ssl init hook was performed in the main loop,
after chroot. A user complained that this was bad behaviour,
because they used the same key/certificate for all of their
services and they didn't want to copy their certificate data into the chroot.
Now, from a security POV, there is no difference between having ssl keys
inside the chroot or storing them outside, because if there is an
exploitable hole in ngircd you can read the key data from memory anyway.
I'll modify the code to allow both behaviours, i.e. it will be called
before chroot() and from inside the Rehash function to allow keys
to be re-loaded (provided they reside inside the chroot...).
Supporting this in gnutls will take some time, though.
If i remember correctly, you can't simply call
gnutls_certificate_free_credentials() on the old x509 context, since it may
still be in use (by active ssl-connections).
I'll have to investigate what the best way to solve this is.
Florian