Conversation

This Tweet was deleted by the Tweet author. Learn more

Replying to

Actually you don't need wildcards, try_files and if not exist proxing the .wellknown requests across all your servers works very well.. (and deny already proxied requests in order to prevent loops) its straight forward nginx config, but i have samples if you like

Replying to

github.com/GrapheneOS/rel is what we ended up doing. The certbot nginx plugin made it too complicated.

github.com

use webroot for certbot to support replicas · GrapheneOS/releases.grapheneos.org@f72c83e

Replying to

And .. github.com/GrapheneOS/rel (which i do not need to tell you, leaves something to be desired ) Btw acme.sh + nginx -s reload as a reload command is way simpler + less dependencies than certbot + plugins asks for..

Replying to

I don't really want to port github.com/tomwassenberg/ to work with something else though.

Replying to

and

If the keys weren't the same across each server, we'd need to have separate SSHFP and TLSA records for each, which we don't want to end up doing. It's a lot simpler to have the same key across them and that seems to make sense. Also fewer certificates spamming CT logs.

1:22 AM · Feb 25, 2021Twitter Web App

Replying to

I see you are actually doing DANE-EE and not DANE-TA which is common for LE. Strict pinning is nice but excludes autorotating your keys with certbot. SSH CA gives you more security and flexibility compared to pinning. I don't see how a few CT logs are a real problem

Replying to

I don't want to simply trust LE since they simply verify domain control via unauthenticated HTTP connections. I don't really see the advantage of having separate keys across servers with the exact same purpose. Since they can be accessed via SSH, that workstation is trusted.

Show replies