I definitely agree it makes little sense anymore to deploy an HTTP only option, and my own apache config for koha has the HTTP ports set to redirect to HTTPS. If this really is a LAN-only installation, with no public access, then you are also likely to have control over the machines accessing the service and can force them to trust a self-signed certificate from the koha server, at least as far as the circulation/staff workstations and any library-provided public access catalog stations are concerned. If this also includes the OPAC catalog for guests, if it really is internal-LAN-only then a number of public wifi solutions will allow you to include a captive portal that can check certificate availability before granting internet access, and deploy the needed certificate as part of onboarding. I am sympathetic, though, to the argument that the same libraries lacking IT capabilities for a public catalog also likely lack capabilities to implement quality wifi onboarding. The LetsEncrypt certificates are free, it's not hard or expensive to buy a domain and get help once to set things up to forward a port from the public internet connection to an internal server so LetsEncrypt can do domain validation. But it's another thing entirely to be sure your server is hardened and sufficiently monitored/maintained in a way you can be comfortable exposing it to the public internet, and not every library can do that. Sometimes there are other reasons to keep a catalog private for local patrons only, too. I feel like the major web browsers are right to implement warnings about HTTP traffic, but too aggressive about including those warnings for traffic to non-routable IPs... but it's not something we have the power to change, so those smaller libraries will have to find a way to live within the new world. *Joel Coehoorn* York University* | *Director of Information Technology Office: 402-363-5603 | @YUITDept <https://twitter.com/YUITDept> *The mission of York University is to transform lives through Christ-centered education and to equip students for lifelong service to God, family and society*. On Wed, Jul 13, 2022 at 2:39 PM C.S. Hayward <c.s.hayward@protonmail.com> wrote:
Using HTTPS for routine web activity is no longer the future of the web; it is the present of the web. Firefox displays intimidating warnings, comparable to an invalid certificate warnings, before letting you access an HTTP connection that cannot be upgraded to HTTPS.
It's not clear to me whether there are any particularly good ways to get a certificate for a server on the LAN. I can see some duct-tape-y switching DNS entries so that you get a Let's Encrypt certificate which is served up for a library.[your domain here] server, but I can't think of any good way to use it.
This would seem to mean that the practice of running a server, available on the LAN as 192.168.x.x or 10.x.x.x, is a casualty of the web being upgraded to HTTPS for normal use. I can see obvious ways of restricting use to a LAN (by limiting connections to a single IP or IP range for a NATted LAN), but just putting something on a LAN at a 192.168.x.x or 10.x.x.x address looks to me like a casualty of change.
For what it's worth...
Br. C.S. Hayward, https://cjshayward.com _______________________________________________
Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha