[tech] SSL on various services with LetsEncrypt

[David Adam]

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@