From trs80 at ucc.gu.uwa.edu.au Sat Dec 1 22:05:55 2018 From: trs80 at ucc.gu.uwa.edu.au (James Andrewartha) Date: Sat, 1 Dec 2018 22:05:55 +0800 (AWST) Subject: [tech] Upgraded SOGo on mussel In-Reply-To: References: Message-ID: On Wed, 21 Jun 2017, David Adam wrote: > On Wed, 21 Jun 2017, James Andrewartha wrote: > > Not that anyone else cares, because it's obviously been broken for months > > and nobody noticed, but SOGo ate its config a while ago, as it is wont to > > do, and after putting it back I was getting an odd error so I decided to > > upgrade it to the Debian version in jessie-backports. After removing the > > various conflicting packages and rebuilding the config plist it still > > didn't work with random errors, but once I removed and reinstalled the > > packages it started working. Well, CalDAV is working, the web interface > > doesn't have any CSS or JS, probably due to some obscure header that needs > > to be sent in the apache config. > > > > Anyway, mussel has a 64bit kernel installed but it doesn't boot into it by > > default. The only interactive users are matt, zarquin, bob and zanchey, I > > propose to reboot it sometime into the 64bit kernel and remove the 32bit > > one. This is relevant because the upstream packages for jessie are 64bit > > only. > > OK by me - do you want to go to a 64-bit userland at the same time, or > stick with mostly 32-bit for now? slapd and apache would be the obvious > winner and loser respectively, I think. Ah-hah! The problem was that /usr/lib/GNUstep/SOGo/WebServerResources was an empty directory, not a symlink to ../../../share/GNUstep/SOGo/WebServerResources as it should have been per the package. In other news, I upgraded to SOGo 4.0.4 from testing before I worked this out and it has a lovely Material Design look now. It's also still pointing at LDAP, not AD. But I've shaved enough of the yak to get my contacts synced from my old phone to my new, so I'll leave it for the time being. -- # 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 / From frekk at ucc.asn.au Fri Dec 7 18:50:11 2018 From: frekk at ucc.asn.au (Felix von Perger) Date: Fri, 7 Dec 2018 18:50:11 +0800 Subject: [tech] SSL on various services with LetsEncrypt Message-ID: <3f1f28c0-8084-c264-0f2d-069edcab34dd@ucc.asn.au> Hi all, [CFE] and I worked on enabling / fixing SSL on a bunch of services today. This hopefully hasn't broken anything significant. * Wiki on mooneye using acmetool o acmetool want wiki.ucc.asn.au wiki.ucc.gu.uwa.edu.au wikisfa.ucc.gu.uwa.edu.au wikisfa.ucc.asn.au o Added redirects to HTTPS versions of the above domains in /etc/apache2/sites-enabled/wiki.conf * Attempted to migrate AD domain controller host certificates on samson o Using certbot and custom scripts calling samba-tool to manually update a TXT record for _acme-challenge.ad.ucc.gu.uwa.edu.au o In order to allow acme to issue a wildcard certificate for *.ad.ucc.gu.uwa.edu.au, the TXT record must be resolvable externally; + Done by setting allow-recursion {any;} in mooneye:/etc/bind/named.conf.options + There doesn't seem to be a way to have more fine-grained access control to recursion/forwarding queries to forward zones while using bind, so this seems like the only option that would work + It also means that anyone can ask mooneye to do DNS lookups for any domain. Is this a bad thing?! o It may be possible to request certificates using HTTP port 80 as the proof of ownership mechanism - however we cannot generate wildcard certificates this way. + Nothing else listens on port 80 on AD DCs + samson.ad.ucc.gu.uwa.edu.au still needs to be externally resolvable - which can only be done in our current software configuration by allow-recursion {any;} * Proxmox (maltair, medico and loveday) - see https://pve.proxmox.com/wiki/Certificate_Management o using `pvenode config set --acme domains=$HOST.ucc.gu.uwa.edu.au;$HOST.ucc.asn.au` o and `pvenode acme cert order` o This is also integrated into the Proxmox web UI, and once acme is configured it will automatically renew certificates when necessary * 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. Please feel free to contact either myself or [CFE] regarding breakages or security hazards introduced by the above changes. Best regards, Felix von Perger [FVP] UCC Wheel Member -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20181207/842f7d3d/attachment.htm From mtearle at ucc.asn.au Fri Dec 7 20:48:04 2018 From: mtearle at ucc.asn.au (Mark Tearle) Date: Fri, 07 Dec 2018 12:48:04 +0000 Subject: [tech] SSL on various services with LetsEncrypt In-Reply-To: <3f1f28c0-8084-c264-0f2d-069edcab34dd@ucc.asn.au> References: <3f1f28c0-8084-c264-0f2d-069edcab34dd@ucc.asn.au> Message-ID: <1544186884.2339929.1602000864.31052A85@webmail.messagingengine.com> On Fri, 7 Dec 2018, at 10:50 AM, Felix von Perger wrote: > > * Attempted to migrate AD domain controller host certificates on > samson > * Using certbot and custom scripts calling samba-tool to manually > update a TXT record for _acme-challenge.ad.ucc.gu.uwa.edu.au > * In order to allow acme to issue a wildcard certificate for > *.ad.ucc.gu.uwa.edu.au, the TXT record must be resolvable > externally; > * Done by setting allow-recursion {any;} in > mooneye:/etc/bind/named.conf.options > * There doesn't seem to be a way to have more fine-grained access > control to recursion/forwarding queries to forward zones while > using bind, so this seems like the only option that would work > * It also means that anyone can ask mooneye to do DNS lookups for > any domain. Is this a bad thing?! > * It may be possible to request certificates using HTTP port 80 as > the proof of ownership mechanism - however we cannot generate > wildcard certificates this way. > * Nothing else listens on port 80 on AD DCs > * samson.ad.ucc.gu.uwa.edu.au still needs to be externally > resolvable - which can only be done in our current software > configuration by allow-recursion {any;} Can you use have the CNAME method for pointing the _acme_challenge elsewhere so you don't have to have recursion turned on? https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation http://strugglers.net/~andy/blog/2018/03/19/lets-encrypt-wildcard-certificates-acme-sh-and-automated-dns-verification/ Mark -- Mark Tearle - mtearle at ucc.asn.au -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20181207/7f63616e/attachment.htm From zanchey at ucc.gu.uwa.edu.au Fri Dec 7 22:10:52 2018 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Fri, 7 Dec 2018 22:10:52 +0800 (AWST) Subject: [tech] SSL on various services with LetsEncrypt In-Reply-To: <3f1f28c0-8084-c264-0f2d-069edcab34dd@ucc.asn.au> References: <3f1f28c0-8084-c264-0f2d-069edcab34dd@ucc.asn.au> Message-ID: 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. > > * 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? > o Using certbot and custom scripts calling samba-tool to manually > update a TXT record for _acme-challenge.ad.ucc.gu.uwa.edu.au > o In order to allow acme to issue a wildcard certificate for > *.ad.ucc.gu.uwa.edu.au, the TXT record must be resolvable > externally; > + Done by setting allow-recursion {any;} in > mooneye:/etc/bind/named.conf.options > + There doesn't seem to be a way to have more fine-grained > access control to recursion/forwarding queries to forward > zones while using bind, so this seems like the only option > that would work It's still broken, but that's because only mooneye knows to forward the zone to samson. We have multiple secondary nameservers which copy the zone data, but do not know about the forwarding. On the whole forward zones are to be avoided. When I set up the adtest zone, I set it up as a full zone, which might be a better option - the configuration is still on mooneye (although disabled). > + 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. > o It may be possible to request certificates using HTTP port 80 as > the proof of ownership mechanism - however we cannot generate > wildcard certificates this way. > + Nothing else listens on port 80 on AD DCs > + samson.ad.ucc.gu.uwa.edu.au still needs to be externally > resolvable - which can only be done in our current software > configuration by allow-recursion {any;} > > * Proxmox (maltair, medico and loveday) - see > https://pve.proxmox.com/wiki/Certificate_Management > o using `pvenode config set --acme > domains=$HOST.ucc.gu.uwa.edu.au;$HOST.ucc.asn.au` > o and `pvenode acme cert order` > o This is also integrated into the Proxmox web UI, and once acme > is configured it will automatically renew certificates when > necessary That is radical. > * 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.) David Adam zanchey@ From trs80 at ucc.gu.uwa.edu.au Fri Dec 7 23:01:43 2018 From: trs80 at ucc.gu.uwa.edu.au (James Andrewartha) Date: Fri, 7 Dec 2018 23:01:43 +0800 (AWST) Subject: [tech] SSL on various services with LetsEncrypt In-Reply-To: <1544186884.2339929.1602000864.31052A85@webmail.messagingengine.com> References: <3f1f28c0-8084-c264-0f2d-069edcab34dd@ucc.asn.au> <1544186884.2339929.1602000864.31052A85@webmail.messagingengine.com> Message-ID: On Fri, 7 Dec 2018, Mark Tearle wrote: > On Fri, 7 Dec 2018, at 10:50 AM, Felix von Perger wrote: > > o Attempted to migrate AD domain controller host certificates on samson > o Using certbot and custom scripts calling samba-tool to manually update a TXT record for > _acme-challenge.ad.ucc.gu.uwa.edu.au > o In order to allow acme to issue a wildcard certificate for *.ad.ucc.gu.uwa.edu.au, the TXT record must be > resolvable externally; > # Done by setting allow-recursion {any;} in mooneye:/etc/bind/named.conf.options > # There doesn't seem to be a way to have more fine-grained access control to recursion/forwarding queries > to forward zones while using bind, so this seems like the only option that would work > # It also means that anyone can ask mooneye to do DNS lookups for any domain. Is this a bad thing?! > o It may be possible to request certificates using HTTP port 80 as the proof of ownership mechanism - however > we cannot generate wildcard certificates this way. > # Nothing else listens on port 80 on AD DCs > # samson.ad.ucc.gu.uwa.edu.au still needs to be externally resolvable - which can only be done in our > current software configuration by allow-recursion {any;} > > Can you use have the CNAME method for pointing the _acme_challenge elsewhere so you don't have to have recursion turned on? > > https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation > > http://strugglers.net/~andy/blog/2018/03/19/lets-encrypt-wildcard-certificates-acme-sh-and-automated-dns-verification/ +1 - I use the acme.sh method used in the second link at work to verify my internal-only domains, it works well. -- # 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 / From trs80 at ucc.gu.uwa.edu.au Fri Dec 7 23:11:39 2018 From: trs80 at ucc.gu.uwa.edu.au (James Andrewartha) Date: Fri, 7 Dec 2018 23:11:39 +0800 (AWST) Subject: [tech] SSL on various services with LetsEncrypt In-Reply-To: References: <3f1f28c0-8084-c264-0f2d-069edcab34dd@ucc.asn.au> Message-ID: 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 / From mtearle at ucc.asn.au Sat Dec 8 06:01:38 2018 From: mtearle at ucc.asn.au (Mark Tearle) Date: Fri, 07 Dec 2018 22:01:38 +0000 Subject: [tech] SSL on various services with LetsEncrypt In-Reply-To: References: <3f1f28c0-8084-c264-0f2d-069edcab34dd@ucc.asn.au> Message-ID: <1544220098.2709030.1602545960.667E64D8@webmail.messagingengine.com> On Fri, 7 Dec 2018, at 3:11 PM, James Andrewartha wrote: > 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? > Perhaps some discussion on which hosts the cert would live upon, and what our security model is here? Mark -- Mark Tearle From zanchey at ucc.gu.uwa.edu.au Sat Dec 8 07:22:26 2018 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Sat, 8 Dec 2018 07:22:26 +0800 (AWST) Subject: [tech] SSL on various services with LetsEncrypt In-Reply-To: References: <3f1f28c0-8084-c264-0f2d-069edcab34dd@ucc.asn.au> Message-ID: 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: > > > [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? The names in those expiry notices have already been renewed; I think the reminder is a red herring. > > > * 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. Right, but this is about allowing recursion for any domain. In any case, it's not actually turned on (allow-recurse still set to the UCC ranges only), so never mind. [DAA] From matt at ucc.asn.au Mon Dec 10 23:14:22 2018 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 10 Dec 2018 23:14:22 +0800 Subject: [tech] secure.ucc ipv6 Message-ID: <6E30F729-FDBE-4474-BEF0-3BA2D5E27787@ucc.asn.au> Hi, I've added ipv6 firewall rules etc for all the services on secure.ucc.asn.au (webmail, imap, smtp submission), and added a AAAA record. If anything breaks let me know. Cheers, Matt From nick at ucc.gu.uwa.edu.au Mon Dec 10 23:27:27 2018 From: nick at ucc.gu.uwa.edu.au (Nick Bannon) Date: Mon, 10 Dec 2018 23:27:27 +0800 Subject: [tech] Koha busybee evening , 2018-12-10 In-Reply-To: <20181121111921.ucsdvpxglrx5h7ft@ucc.gu.uwa.edu.au> References: <20181115061900.x4dyyconmasscji2@ucc.gu.uwa.edu.au> <20181112143244.lop5lgvgibhtm2mx@ucc.gu.uwa.edu.au> <20181121111921.ucsdvpxglrx5h7ft@ucc.gu.uwa.edu.au> Message-ID: <20181210152727.xaphnk7pedwb6bgq@ucc.gu.uwa.edu.au> Uni Sfa wrote at https://www.facebook.com/groups/UniSFA/permalink/10156351122011026/ on 2018-12-06 at 10:35 PM: > Hey Unisfans > Do you love databases? Do you need some sweet management experience? Or > do you just love Unisfa so much you'd be willing to fistfight > Deepthought? Well Unisfa is looking for another Koha master to help us > manage are library. > > Ideally we're looking for a first or second year - but anyone who is > keen and will be around would also be ideal. SQL experience is desired, > but certainly not required. The only real requirements are a willingness > to learn and a love of the club. > > If this sounds like you, comment below or message the page/your local > homegrown committee member and be prepared to come to training monday > evening. > > EDIT: training will be Monday Evening (the 10th). Plenty of projects going on tonight, but not a lot of UniSFAns... Blair and I were able to snapshot and restore the unisfa-koha VM through the proxmox interface, so then we went ahead with software upgrades. It's now running Debian 9.6 (stretch) and Koha 18.11. So - next time? I'd be keen to treat it as a scheduled "Library meeting", a la Sunday 20180527-1400 - any appetite for one of those over the coming holidays? On Wed, Nov 21, 2018 at 07:19:21PM +0800, Nick Bannon wrote: > However now we still need some kind of introduction and technical > handover. [...] > Ideally, we're after 1st or 2nd year members with an interest in CS, > sysadmin, LAMP and/or programming. Any member of both UCC and UniSFA is > a good candidate. > * Testing checklist: _is_ Koha functional? What needs checking, with what logins? * Online Public Access Catalogue/OPAC interface: http://unisfa-koha.ucc.asn.au/ * INTRA login interface http://unisfa-koha.ucc.asn.au:8080/ * Logins and familiarisation * http://unisfa-koha.ucc.asn.au/ OPAC * http://unisfa-koha.ucc.asn.au:8080/ admin interface * SSH * mariadb/mysql , mysqldump * phpmyadmin * proxmox * unisfa-koha VM * VM host interface (proxmox), can be checked with "unisfa" user * configure email (backups, overdue notifications) * configure letsencrypt for HTTPS * /etc/cron.daily/koha-common * configure remote logging, fail2ban * offsite backups * regular OS updates * regular Koha upgrade * deb http://debian.koha-community.org/koha stable main Also: * update UniSFA mail aliases mooneye:/etc/aliases for 2018/2019 * subscribe librarian? to https://lists.ucc.gu.uwa.edu.au/mailman/listinfo/unisfa-committee -- Nick Bannon | "I made this letter longer than usual because nick-sig at rcpt.to | I lack the time to make it shorter." - Pascal From trs80 at ucc.gu.uwa.edu.au Mon Dec 17 11:51:48 2018 From: trs80 at ucc.gu.uwa.edu.au (James Andrewartha) Date: Mon, 17 Dec 2018 11:51:48 +0800 (AWST) Subject: [tech] SSL on various services with LetsEncrypt In-Reply-To: References: <3f1f28c0-8084-c264-0f2d-069edcab34dd@ucc.asn.au> Message-ID: 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 /