It occurred to me shortly after clicking Submit that the best place to discuss this: https://bugs.launchpad.net/evergreen/+bug/1882967 <https://bugs.launchpad.net/evergreen/+bug/1882967> would actually be this mailing list rather than LP.
So, here it is again: This is a wishlist item to start some discussion around making 2 changes to Evergreen's handling of TLS. 1, given the existence of LetsEncrypt and the fact that encrypted communications aren't that large a drain on modern hardware, TLS should simply be required and assumed across the board. This could be reflected in our sample configs. 2, Enforcing #1 should also be the responsibility of apache or nginx, not OpenILS::WWW::EGCatLoader. (This is essentially the case already in many installations because redirects are so easy.) This would allow proxying to be simpler because you only need to manage certs in a single place (nginx, haproxy, whatevs) and could then use HTTP on the backend. Standing up a local test server would be significantly simpler, though Chrome's insistence on a TLS connection for localhost websocket connections is beyond our control. (Maybe more testing with FF? just requires changing wss:// to ws://...) Does anyone have any strong feelings about this? My inclination would be for the Evergreen backend not to even know if it’s behind TLS because you’re handling that before a request even hits us, or if it’s a localhost VM you don’t want to bother. Jason -- Jason Boyer Senior System Administrator Equinox Open Library Initiative phone: +1 (877) Open-ILS (673-6457) email: [email protected] web: https://EquinoxInitiative.org/
