[tech] SSL on various services with LetsEncrypt

[James Andrewartha]

So on the RADIUS cert, the cause of the problem (Windows devices refuse to 
connect to the UCC and UCC-5 SSIDs) is that the cert is incorrectly signed:

samson certs # pwd
/etc/freeradius/3.0/certs
samson certs # openssl x509 -text -noout -in server.pem
[snip]
            X509v3 Extended Key Usage:
                TLS Web Client Authentication

When it needs to be TLS Web Server Authentication. So regenerating it with 
the correct attributes would probably solve the problem. I am happy to 
advice but would rather someone in the clubroom does it so it can be 
tested. It may or may not require existing non-Windows clients to manually 
rejoin the network.

On Fri, 7 Dec 2018, James Andrewartha wrote:
> On Fri, 7 Dec 2018, David Adam wrote:
> > On Fri, 7 Dec 2018, Felix von Perger wrote:
> > >  * 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 /