[tech] SSL on various services with LetsEncrypt

James Andrewartha trs80 at ucc.gu.uwa.edu.au
Fri Dec 7 23:11:39 AWST 2018


On Fri, 7 Dec 2018, David Adam wrote:

> On Fri, 7 Dec 2018, Felix von Perger wrote:
> > [CFE] and I worked on enabling / fixing SSL on a bunch of services today. This
> > hopefully hasn't broken anything significant.

There are a bunch of Let's Encrypt certs that aren't renewing properly, 
there was an auto-discard notification which hostmasters would have seen, 
I'll forward it to wheel at . Can we move the webhosting over to using a 
wildcard?

> >  * Attempted to migrate AD domain controller host certificates on samson
> 
> Why do we need an externally-signed certificate for AD? Can't we just use 
> the UCC CA or the Samba CA?

It is a bit nicer, plus we never have to worry about renewing it manually 
when the time comes.

> >          + It also means that anyone can ask mooneye to do DNS lookups
> >            for any domain. Is this a bad thing?!
> 
> It can be used in DNS amplification attacks, so we should turn that off.

Let's Encrypt by design do not publish which IPs may be used to query the 
nameserver to verify ownership, so we can't in practice restrict them 
anyway.

> >  * Also planned to generate an SSL certificate for RADIUS (also on
> >    samson) using HTTP
> >      o Windows will not break when connecting to wifi if a valid
> >        (trusted) server certificate is presented for the RADIUS server
> >        hostname (AFAIK).
> >      o Note: this can be done using samson.ucc.gu.uwa.edu.au rather
> >        than samson.ad.ucc.gu.uwa.edu.au (since subdomains of ad.ucc may
> >        not be resolvable externally)
> >      o Alternatively RADIUS could be configured to use the same
> >        wildcard certificate as AD, provided it is possible to generate one.
> >          + Why not just do that? It /would/ probably work but only if
> >            the AD wildcard certificates work as well, which they don't
> >            seem to currently.
> 
> RADIUS - or more particularly, the certificate used with the wifi 
> authentication (EAP-PEAPv0/MSCHAPv2) - is kind of a special case. Because 
> the clients have no way of knowing or controlling which server they are 
> connecting to server, there is generally a trust-on-first-use (macOS, iOS) 
> or a special setting (Android, Windows - not sure about Windows 10) to 
> specify the certificate. In older versions of Windows your certificate 
> needed a special Extended Key Usage attributes set.
> 
> Here is us thrashing around trying to get it set up in 2010:
>   https://lists.ucc.gu.uwa.edu.au/pipermail/tech/2010-April/003788.html
> 
> In any case, you can use a certificate with whatever name you like - we 
> used to use `secure.ucc.asn.au` but you could get one for 
> `wifi.ucc.asn.au` or similar if you wanted. The client connects to "UCC", 
> and the network access point decides where to send the request; the name 
> doesn't matter. (I hope that makes sense.)

Yes please do not fuck with RADIUS certs, on macOS/iOS you'll have to 
manually rejoin every time the certificate changes, which would be every 
two months under standard Let's Encrypt settings. Admittedly I haven't 
tested this recently but I can't imagine it's changed. Best practice IMHO 
is a private CA issuing a fairly long-lived (5-10 years, since you'll have 
to change it as new crypto protocols come out/old ones get broken) cert.

Why? Let's say you go into the settings and only trust Let's Encrypt 
issued certs, unless you also put a server name restriction on that, 
anyone could get a Let's Encrypt cert for any domain and put up a fake UCC 
SSID and start stealing MS password hashes.

-- 
# TRS-80              trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \
# UCC Wheel Member     http://trs80.ucc.asn.au/ #|  what squirrels do best     |
[ "There's nobody getting rich writing          ]|  -- Collect and hide your   |
[  software that I know of" -- Bill Gates, 1980 ]\  nuts." -- Acid Reflux #231 /


More information about the tech mailing list