Since it’s 2017 and that; Didn’t want to rush into this. Thought I should finally enable TLS/SSL since it’s free. I’m not sure I entirely agree with the arguments for a site like mine (wouldn’t metadata be the biggest problem?), but it’s pointless trying to argue against the tide; One thing though: Zscaler, anyone who has had to browse through that realises that TLS/SSL isn’t bulletproof. I understand why that exists as a product, but, gah, as an end user it’s just horrible.
The EFF site will guide you down the certbot-auto route for NetBSD, which is silly as there is a py27-certbot package - just use that.
Bozohttpd works fine with Let’s Encrypt, the only issue is that it either serves https OR http, unfortunately not both at the same time. I haven’t yet figured out a way to redirect traffic between ports so that’s meant I’m effectively running two webservers at the moment as per this rc.conf approach. I.e:
- Duplicate
/etc/rc.d/httpd
to/etc/rc.d/httpsd
. - Edit and make sure to change
name
tohttpsd
andcommand
so command is explicitly calling/usr/libexec/httpd
- Add a
$procname=$name
line (otherwise it’ll get confused between httpd and httpsd and think they are the same). - Change
required_dirs
to$httpsd_wwwdir
- In rc.conf have both a
httpsd=YES
and ahttpd=YES
Then I have the following entries in rc.conf
for http:
httpd_flags="-S bozohttpd -v /var/www/vroot -M .html 'text/html; charset=utf-8' '' '' -M .xml 'text/xml; charset=utf-8' '' ''"
Whilst httpsd has these extras:
-Z /usr/pkg/etc/letsencrypt/live/atomicules.co.uk/fullchain.pem /usr/pkg/etc/letsencrypt/live/atomicules.co.uk/privkey.pem -z 'EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;'
Since running two webservers isn’t ideal I think I’ll ultimately have to redirect all traffic with the firewall (or run a proxy I suppose?), but that is going to have to wait until I perform some server maintenance and finally switch from IPFilter to NPF (which I should be able to do now I’m running on KVM).
[EDIT: 2017-07-30] Note: It’s advisable to set procname
in both /etc/rc.d
files. I think otherwise the start up order matters (god knows how it gets confused, but I found setting procname
in both worked).