Skip to content

A new server, and a few more words about LetsEncrypt.

UNIX

Back in April some jackass promised that there would be a follow-up post about migrating bsd-box.net to use the LetsEncrypt CA.
Oh right, that was me.

As usual life interfered, but here's the followup: The bsd-box.net server has been replaced with a shiny new machine, LetsEncrypt is still my CA of choice for this system, and a bunch of other things have changed. More below the jump.

So this is the first blog post on the shiny new bsd-box.net server - I would like to introduce you all to nibbler.bsd-box.net:

CPU: Intel(R) Xeon(R) CPU           E5645  @ 2.40GHz (2400.14-MHz K8-class CPU)
real memory  = 137443147776 (131076 MB)
avail memory = 133546471424 (127359 MB)
FreeBSD/SMP: Multiprocessor System Detected: 24 CPUs
FreeBSD/SMP: 2 package(s) x 6 core(s) x 2 hardware threads
ada0: <SanDisk SDSSDX480GG25 R201> ATA8-ACS SATA 3.x device

That's 2x 6 cores (plus HyperThreading), with 128GB of physical RAM, and 480GB of SSD storage.
The system it replaced was dual-core plus HyperThreading, with 2GB of physical RAM and 128GB of spinny-disk storage.

"You may notice a slight performance improvement."


Along with the shiny new server comes a shiny new DNS configuration.
I'm still running BIND, but I'm taking advantage of the automatic DNSSEC management that came along in BIND 9.9 & have enabled DNSSEC on the bsd-box.net zone. It is now "fully validated" with a key loaded at the .net zone, and the first automatic key rollover is scheduled for February 1, 2017 at 15:04:57 UTC. Hopefully nothing breaks.

Folks may be wondering why I'm signing my little zone - it has a lot to do with SSH.  Specifically SSH key fingerprints.

I've been publishing server SSH key fingerprints in DNS using the SSHFP resource record for some time, but without DNSSEC I can't really advocate trusting that data to authenticate the key.
With DNSSEC that data is at least a little more trustworthy: I could magic up a case of tragic cache poisoning where the .net zone data someone gets has forged keys, but the chance of that happening is pretty low, and made lower by the fact that a DNSSEC-validating resolver will probably have the .net zone key cached, and anyone accessing bsd-box.net through a validating resolver on a regular basis would have that key cached a lot of the time as well. 


Finally I promised you all some more words on LetsEncrypt.

As you can tell by clicking on the friendly lock icon, I'm still using LetsEncrypt, but there have been some hiccups in getting it all running smoothly.

Those of you paying attention may have noticed the bsd-box.net certificate expired for a day.
That was due to a broken cron job and was an easy fix, but this lead me down the rabbit hole of the letsencrypt.sh script I was using to do the ACME challenge/response handling having a bunch of other errors.

Ultimately I wound upinstalling the py-certbot port, which is the client the LetsEncrypt folks recommend, and I believe that will resolve the bulk of the issues I had. The next expiration is April 12, and I'll watch the auto-renewal closely.
The documentation for certbot is a bit lacking in some areas (like "There is no goddamn manpage! What the fuck is WRONG with you people?!"), and this may be the subject of a future pull request to fix this glaring oversight.

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

No comments

Add Comment

E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
To leave a comment you must approve it via e-mail, which will be sent to your address after submission.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA

Twitter, Pavatar, Gravatar author images supported.
Form options