[sf-lug] SF-LUG (& BALUG) SSL/TLS certs renewed, etc. (thanks to https://letsencrypt.org/)

Wed Mar 2 08:00:44 PST 2016

Yes, renewed, and noted on my calendar:
2016-05-30T12:59:00+0000 BALUG/SF-LUG letsencrypt.org SSL cert expires
for host(s): www.balug.org, www.sf-lug.org, www.ipv6.balug.org,
www.ipv6.sf-lug.org, balug.org, sf-lug.org, archive.balug.org,
www.archive.balug.org, beta.balug.org, www.beta.balug.org,
ipv6.balug.org, new.balug.org, lists.new.balug.org, www.new.balug.org,
secure.balug.org, www.secure.balug.org, test.balug.org,
php.test.balug.org, www.php.test.balug.org, www.test.balug.org,
wiki.balug.org, www.wiki.balug.org, ipv6.sf-lug.org, sf-lug.com,
ipv6.sf-lug.com, www.ipv6.sf-lug.com, www.sf-lug.com, sf-lug.info,
ipv6.sf-lug.info, www.ipv6.sf-lug.info, www.sf-lug.info

So ... have SSL/TLS available for most all SF-LUG and BALUG websites.
Note also ...
Not included in the above:
SF-LUG: list site(s)
BALUG: [www.]balug.org (got cert but can't use it for free on hosted
DreamHost.com)
Note also that many of the above are non-canonical forms, and will
redirect to the canonical (for SF-LUG, most notably to www.sf-lug.org).
Also, not all of the above are necessarily (yet) (fully) implemented as
web sites.
The [www.]ipv6 sites are generally intended to be IPv6 only. :-)
Note, however, at least last I checked, letsencrypt.org can't yet do
direct validation of IPv6 only sites (forthcoming, but they don't have
specific timeline on that yet).  So, to do the validation checks for
letsencrypt.org for those sites, I've thus far temporarily added an IPv4
address before validation, and then removed them after completing
validation.

One single cert for both SF-LUG and BALUG?
Yes, as they're presently all running off of a single (virtual) host,
and virtual name hosted from same (Apache) web server, seemed more
appropriate to have a single cert, rather than multiple certs.  If/when
they get separated to again have separate (physical or virtual) hosts
and servers, then it would make more sense to have separate certificates
for each.  And with letsencrypt.org, since there's no monetary cost for
the certs, that's easy enough to split out later if/when desired,
without monetary cost being a factor/consideration.

Redirect from http to https?  Not generally doing that present.  Perhaps
in future (there are various debatable pros and cons).  I think thus far
the only bit I specifically redirect to https are the BALUG wiki bits
that would otherwise send passwords or the like in the clear.  But those
might not be fully effective security-wise unless one only uses https
for all the wiki bits.  At least with valid CA signed certs, none of the
warnings about snake-oil self-signed cert anymore. :-)

Oh, and yes, SF-LUG does also have it's own namespace on the BALUG
wiki:
https://www.wiki.balug.org/wiki/doku.php?id=start&idx=sf-lug
I long ago separated out the SF-LUG specific wiki stuff into
it's own namespace, so that if/when SF-LUG ever did wiki on its own
separate server, most of the work of separating out the SF-LUG specific
stuff was already done.  Have to register on the wiki to edit,
and have to be manually added/approved by sysadmin (due to abuse by
spamvertizing bots ... more of the latest round on that:
Bloody stupid spamvertising bots ...
The dokuwiki playground - which allows unauthenticated users to
edit it.  Long time ago, I set it up so that with about 25 minutes of
non-use it resets to its initial default configuration.  Well, stupid
spamvertizing bots have been pounding away on it changing it more
frequently than that.
# ls /var/lib/dokuwiki/data/attic/playground/ | wc -l
2524
#
Just stupid short spambertizing, but they keep rapidly changing it,
etc., wasting resources and bandwidth.
Anyway, changed the permissions - no more editing by unauthenticated
users.  That should prevent them from (ab)using it, and once it goes
that approximately 25 mintutes without being used at all, it revert and
drop all their spamvertizing.

> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
> Subject: SF-LUG & SSL/TLS: now proper certs on SF-LUG sites thanks  
> to https://letsencrypt.org/ :-)
> Date: Wed, 09 Dec 2015 06:36:33 -0800

> 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