<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hi all,</p>
    <p>[CFE] and I worked on enabling / fixing SSL on a bunch of
      services today. This hopefully hasn't broken anything significant.<br>
    </p>
    <ul>
      <li>Wiki on mooneye using acmetool<br>
      </li>
      <ul>
        <li>acmetool want wiki.ucc.asn.au wiki.ucc.gu.uwa.edu.au
          wikisfa.ucc.gu.uwa.edu.au wikisfa.ucc.asn.au</li>
        <li>Added redirects to HTTPS versions of the above domains in
          /etc/apache2/sites-enabled/wiki.conf<br>
        </li>
      </ul>
      <li>Attempted to migrate AD domain controller host certificates on
        samson</li>
      <ul>
        <li>Using certbot and custom scripts calling samba-tool to
          manually update a TXT record for
          _acme-challenge.ad.ucc.gu.uwa.edu.au<br>
        </li>
        <li>In order to allow acme to issue a wildcard certificate for
          *.ad.ucc.gu.uwa.edu.au, the TXT record must be resolvable
          externally;</li>
        <ul>
          <li>Done by setting allow-recursion {any;} in
            mooneye:/etc/bind/named.conf.options</li>
          <li>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<br>
          </li>
          <li>It also means that anyone can ask mooneye to do DNS
            lookups for any domain. Is this a bad thing?!</li>
        </ul>
        <li>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.<br>
        </li>
        <ul>
          <li>Nothing else listens on port 80 on AD DCs<br>
          </li>
          <li>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;}<br>
          </li>
        </ul>
      </ul>
      <li>Proxmox (maltair, medico and loveday) - see
        <a class="moz-txt-link-freetext" href="https://pve.proxmox.com/wiki/Certificate_Management">https://pve.proxmox.com/wiki/Certificate_Management</a></li>
      <ul>
        <li>using `pvenode config set --acme
          domains=$HOST.ucc.gu.uwa.edu.au;$HOST.ucc.asn.au`</li>
        <li>and `pvenode acme cert order`</li>
        <li>This is also integrated into the Proxmox web UI, and once
          acme is configured it will automatically renew certificates
          when necessary</li>
      </ul>
      <li>Also planned to generate an SSL certificate for RADIUS (also
        on samson) using HTTP</li>
      <ul>
        <li>Windows will not break when connecting to wifi if a valid
          (trusted) server certificate is presented for the RADIUS
          server hostname (AFAIK).<br>
        </li>
        <li>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)</li>
        <li>Alternatively RADIUS could be configured to use the same
          wildcard certificate as AD, provided it is possible to
          generate one.</li>
        <ul>
          <li>Why not just do that? It <i>would</i> probably work but
            only if the AD wildcard certificates work as well, which
            they don't seem to currently.<br>
          </li>
        </ul>
      </ul>
    </ul>
    <p>Please feel free to contact either myself or [CFE] regarding
      breakages or security hazards introduced by the above changes.<br>
    </p>
    <p>Best regards,<br>
      Felix von Perger [FVP]<br>
      UCC Wheel Member<br>
    </p>
    <p><br>
    </p>
  </body>
</html>