INITIALIZE-INSTANCE (SSL-ACCEPTOR) should not take TRUENAME of cert-files

[frodef]

I have a HT SSL server, with certificate files that get automatically updated by some shell scripts (i.e. outside of the CL image). The updated certificate files are pointed to by symlinks. However, these symlinks are dereferenced at "boot" time by INITIALIZE-INSTANCE :AFTER (SSL-ACCEPTOR). Consequently, when the symlinks are updated by the shell scripts, the HT instance keeps using the old certificate which eventually expires. And then my server fails.

A simple fix would be to move the calls to NAMESTRING and TRUENAME into INITIALIZE-CONNECTION-STREAM (SSL-ACCEPTOR). This is in ssl.lisp. This would make the INITIALIZE-INSTANCE :AFTER (SSL-ACCEPTOR) method obsolete, it seems to me.

[avodonosov]

@frodef , you can just subclass HUNCHENTOOT:SSL-ACCEPTOR, and override the INITIALIZE-CONNECTION-STREAM with whatever logic you need.

Current Hunchentoot approach of reading certificate on every request is suboptimal - redundant file reading and certificate loading. It would be better to load the certificate once into a CTX object (probably stored as a slot of SSL-ACCEPRTOR), and then reuse this CTX when establishing SSL session for a connection.

Tha'ts how it's done in cl+ssl example:
https://github.com/cl-plus-ssl/cl-plus-ssl/blob/1e2ffc9511df4b1c25c23e0313a642a610dae352/examples/example.lisp#L99
https://github.com/cl-plus-ssl/cl-plus-ssl/blob/1e2ffc9511df4b1c25c23e0313a642a610dae352/examples/example.lisp#L109

Your may want such reuse too, only in your case you will need additional logic to re-iinitialize the CTX when cert files are replaced. Either using slime, or create some HTTP endpoint that you script can call to initialize the reloading, or just every minute.

[frodef]

@avodonosov Thanks, I agree that what you outline is the correct way.

However, it seems to me that what I reported could/should be considered a bug. The certificate-file slots in SSL-ACCEPTOR get modified at initialization-time in a way that seems to me to be plain wrong (even though it's quite understandable how it ended up that way). Part of the problem I think is that (sbcl) TRUENAME dereferences symlinks. I'm not entirely sure that's warranted or even consistent across unix CLs (?).