Florian's rambling place

Let’s Encrypt certificates for private servers

published 2016-01-30 10:38:00

At the end of January 2016 Let's Encrypt fixed the last bug which prevented letsencrypt-remote from authenticating via DNS.

It is now possible to generate TLS certificates for private servers if you can delegate name resolution via your DNS provider.

Let's say you want to generate a certificate for use on your Laptop. You first need to create a subdomain pointing to Something like this in your zone for localhost.example.com:

localhost  IN A

Additionally you need to delegate _acme-challenge.localhost.example.com to an IP which is reachable by the Let's Encrypt servers and where you can access DNS port 53. For example your web server if you have one:

_acme-challenge.localhost  IN NS  www

If you use your web server, you could use ssh to forward the port 8053 to your laptop:

$ ssh root@example.com -R 8053:localhost:8053

You then need to use something to forward remote UDP packets from port 53 of the server to the forwarded TCP port 8053, for example socat:

# socat -T15 udp4-recvfrom:53,reuseaddr,fork tcp:localhost:8053

Now on your laptop you can use letsencrypt-remote to create a certificate using DNS:

% letsencrypt-remote --dns localhost.example.com

If everything worked correctly:

  • letsencrypt-remote should have started a DNS server
  • requested certificate signing
  • the Let's Encrypt servers should be delegated to your server for the DNS query
  • the request be forwarded to your laptop
  • the answer sent back
  • and you got a signed certificate for localhost.example.com

This also works for other private ip ranges like or

New statically generated website using Lektor

published 2016-01-18 11:40:00

After several years and multiple attempts, I finally have a website again.

I tried quite a few static website generators, including starting my own, until I finally settled with the recently announced Lektor.

The main addition to Lektor is my reStructuredText plugin lektor-rst. I had all the old content in rst already and I favour it over markdown.

The source code for my website is available on GitHub at https://github.com/fschulze/florian-schulze.

Proper exit code for buildout generated scripts

published 2010-09-24 15:30:00

I recently ran into the issue that our Hudson installation didn't report test failures. After digging for a bit, I discovered, that scripts installed by zc.recipe.egg don't return the exit code for some cases. There is a bugreport at https://bugs.launchpad.net/zc.buildout/+bug/164629. In our case the generated coverage script depended on this and because the sys.exit was missing, the test failures were masked.

The following is a way to fix this in your buildouts now until it's fixed in zc.buildout:

extensions = buildout.extensionscripts
extension-scripts =

The patchScriptGeneration function in src/buildout-utils.py looks like this:

def patchScriptGeneration(buildout):
    from zc.buildout import easy_install
    if not 'sys.exit(' in easy_install.script_template:
        easy_install.script_template = easy_install.script_template.replace(

mr.developer 1.3 - Fewer surprises

published 2009-11-15 15:20:00

The last releases of mr.developer (1.2 and 1.3) reduce the amount of surprises.

The packages from auto-checkout are now automatically added and removed from the list of development packages when you switch buildout configurations. Before you had to run develop reset and rerun buildout for that to work. If you have an existing checkout, you may want to reset it, so that this change is picked up.

The last used buildout configuration is now read directly. That means if you change source declarations in your buildout configuration, then you don't have to rerun buildout anymore for mr.developer to pick up those changes. You still have to run buildout after changing the develop status of a package, but that's the same as with a plain buildout without mr.developer.

Snakes on a cat!

published 2009-11-05 09:31:00

Since I started to tame the snakepit, I made many improvements to make it even less scary.

The python buildout now auto detects the platform you are on, so it works for many more systems then just Mac OS X without a custom configuration. On Mac OS X it automatically detects whether you are on Leopard or Snow Leopard. Since today it also works on Snow Leopard with 32bit CPUs.