Daniel Micay on Twitter: "@NicoBerlee I don't really want to port https://t.co/qkFoK2MUgG to work with something else though." / Twitter

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

2

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

1

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..

1

Daniel Micay

@DanielMicay

Replying to

@NicoBerlee

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

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

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

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

1

Show replies

Conversation