[sf-lug] SF-LUG & SSL/TLS: now proper certs on SF-LUG sites thanks to https://letsencrypt.org/ :-)

Michael Paoli Michael.Paoli at cal.berkeley.edu
Wed Dec 9 06:36:33 PST 2015


Thanks to:
https://letsencrypt.org/
SF-LUG now has proper SSL/TLS cert(s) covering the SF-LUG sites:
https://www.sf-lug.org/
https://sf-lug.org/
https://www.ipv6.sf-lug.org/
https://ipv6.sf-lug.org/
https://www.sf-lug.com/
https://sf-lug.com/
https://www.ipv6.sf-lug.com/
https://ipv6.sf-lug.com/

One may wish to note:

Not (yet?) included: list host: linuxmafia.com - though it has SSL/TLS,
it doesn't yet have valid recognized CA signed cert (unless you
recognize and trust the linuxmafia.com certificate authority ;-)).

At some point we should agree upon and use canonical form of site and do
301 redirect to canonical (for at least the non-list sites).  I'd
recommend canonical be www.sf-lug.org
and redirect the others there.  The only open question on that may be
should the redirect be to https, or should it use same protocol as the
browser requested.  Note that many sites now, for security, etc.
reasons, are redirecting http to https - including for all site
content.  This seems to be the general trend - e.g. to deprecate and
eventually phase out http, replacing it with https.

These SF-LUG sites use SNI[1], as they share IPv4 address and port with
other non-SF-LUG sites (hosted on non-SF-LUG host), so older (ancient)
browsers won't work properly with that (they'll get a default non-SF-LUG
cert that doesn't match the SF-LUG site names).  I could give the SF-LUG
sites their own IPv6 address (no shortage there) so they could
use separate VirtualHost configuration in Apache ... that would solve
the issue for non-SNI browsers using IPv6 ... but are there any non-SNI
browsers (which are generally quite old anyway) that are IPv6 capable?
So ... it may not be worth the bother (at least yet?) to use additional
IPv6 addresses for that ... particularly if we want to redirect to a
canonical name, and for the near to at least medium-term future, we also
need to continue to support IPv4 webserver.  Though most all browsers
are now, and have long been IPv6 capable, many client systems upon which
they run still often have only IPv4, even if they're otherwise IPv6
capable (e.g. ISP isn't yet providing IPv6, or end user's older
"home router" only gives IPv4 to the client hosts).

The [www.]ipv6.sf-lug.{org,com} sites - I had to temporarily add IPv4
addresses, and then removed them after, as they were needed for the
present
letsencrypt certonly --manual
validation, as that doesn't yet support IPv6 only sites[2] - letsencrypt
is still only recently into their Public Beta[3] phase.

footnotes/references:
https://letsencrypt.org/

1. https://en.wikipedia.org/wiki/Server_Name_Indication
    https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

2. https://community.letsencrypt.org/t/support-for-ipv6-only-hosts/354/27
    https://github.com/letsencrypt/letsencrypt/issues/180
    https://github.com/letsencrypt/boulder/issues/593
    https://github.com/letsencrypt/letsencrypt/issues/1466
    https://community.letsencrypt.org/t/support-for-ipv6-only-hosts/354/27

3. https://letsencrypt.org/2015/12/03/entering-public-beta.html





More information about the sf-lug mailing list