getting grip of reality after moving is not easy in some situations.

when everything is still fresh, and on the other hand - so well known :) you know obviously that stopgaps tend to last for years after they were put “just for a moment”?

my december cleaning started with true horror of moving my emails server from FreeBSD 9-STABLE (just EoLed) to 11-STABLE. traditional make buildworld; make kernel KERNCONF=server; mergemaster -FiU; make installworld; reboot didn’t work, but (WTF?!) the same sources were able to give me working build when i did make buildworld buildkernel; make installkernel and so on. for some reason, with the first sequence - cam.c dropped multiple warnings treated as error. and build failed.

second change was refreshing of certificates, because (StartCom was totally compromised). choosing right port was not easy, as it seems FreeBSD has like five different ones, but each requiring hundreds of dependencies. so i settled with certbot - supported by EFF. so, stopping nginx services, getting the certs and starting nginx is pretty simple:

# pkg install py27-certbot
 ! of course, they're going to change the name tomorrow...
# service nginx stop
 ! we have to stop nginx to replace certs
#certbot certonly --standalone -d me.mydomain.com
 ! it needs to be available from the internet and you can chain more than one:
 ! -d [second] -d [third] etc

of course you’ll need to set rescue e-mail, accept policy and then have fun with new certificates.

they are put by default in special dir:

/usr/local/etc/letsencrypt/live/me.mydomain.com

so the only major thing to do is modify nginx cert configuration:

ssl on;
    ssl_certificate /usr/local/etc/letsencrypt/live/me.mydomain.com/fullchain.pem;
    ssl_certificate_key /usr/local/etc/letsencrypt/live/me.mydomain.com/privkey.pem;

    ssl_prefer_server_ciphers on;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
    ssl_session_cache shared:SSL:10m;

now you can start nginx again:

service nginx start

…and it’s much better now. next thing you can do is reconfigure mail server certs, and then of course automate it.