Closed jkamdjou closed 1 year ago
(Probably) Get rid of the ./build folder, and add this build to CI instead (cc @cameron-dunn-sublime let me know what you prefer)
Is this still relevant? I don't see a .build
folder in the PR.
(Probably) Get rid of the ./build folder, and add this build to CI instead (cc @cameron-dunn-sublime let me know what you prefer)
Is this still relevant? I don't see a
.build
folder in the PR.
@cameron-dunn-sublime whoops - what i actually meant is that we're building from ./nginx-letsencrypt/
, and what we probably want to do instead is publish the build to sublimesec/nginx-letsencrypt
like we do with our other images
updated the TODO to be more clear
Just curious: how does this handle cert updates/refresh? Let's encrypt usually gives you very short lived certs that have to be renewed either manually or automatically by exposing something that let's encrypt can hit. I run this exact setup for my personal server and it works great other than having to refresh every few months.
Just curious: how does this handle cert updates/refresh? Let's encrypt usually gives you very short lived certs that have to be renewed either manually or automatically by exposing something that let's encrypt can hit. I run this exact setup for my personal server and it works great other than having to refresh every few months.
every time you restart the image the startup script refreshes the cert automatically using certbot
:
Just curious: how does this handle cert updates/refresh? Let's encrypt usually gives you very short lived certs that have to be renewed either manually or automatically by exposing something that let's encrypt can hit. I run this exact setup for my personal server and it works great other than having to refresh every few months.
every time you restart the image the startup script refreshes the cert automatically using
certbot
:
@jkamdjou So this will renew the cert every time the cron update script runs? There's a limit of 5 duplicate certs per week...
I consolidated the two Docker Compose files into a single one. You can run the SSL mode by running either of the following:
LETSENCRYPT_ENV=certbot.env docker compose --profile letsencrypt up -d
LETSENCRYPT_ENV=certbot.env COMPOSE_PROFILES=letsencrypt docker compose up -d
The normal docker compose up -d
functionality is untouched.
cc @madirey
Just curious: how does this handle cert updates/refresh? Let's encrypt usually gives you very short lived certs that have to be renewed either manually or automatically by exposing something that let's encrypt can hit. I run this exact setup for my personal server and it works great other than having to refresh every few months.
every time you restart the image the startup script refreshes the cert automatically using
certbot
: https://github.com/sublime-security/sublime-platform/pull/81/files#diff-983b4a5265477c1a7aebd4ea31b862602fd5234e911457a2da3f83816ede9d93R38@jkamdjou So this will renew the cert every time the cron update script runs? There's a limit of 5 duplicate certs per week...
that was my worry... does the cron update have to restart the image every time it runs? maybe we want an explicit flag to renew or something if not, and users have to do it manually (which should be like every 3 months? which sounds fine for now)
https://github.com/sublime-security/sublime-platform/pull/81/commits/5b2de4a3807ebcb0f1ce327ebf63ec2a8ccfa477 checks for existence of certbot.env
and uses @hugh-sublime 's new profile when it exists. I'm still not sure if we will hit the rate limit. Probably gonna have to try it tomorrow.
Also needs https://github.com/sublime-security/sublime-platform/pull/84
When spinning up Sublime on a remote host that isn't in a VPN, such as a DigitalOcean droplet, I found myself uncomfortable proceeding through setup and submitting sensitive creds over the wire in the clear. I don't think I'll be alone.
Users can follow these steps to get SSL (will add to the docs after this is merged):
subliiime.com
) if you don’t have one yet, or use a subdomainwww
pointing tosubliiime.com
.curl -sL https://sublimesecurity.com/install.sh | sh
cd sublime-platform
(+ until this is merged, copy files fromjosh.letsencrypt
branch into this directory)(sudo) docker compose down
Sublime config
certbot.env.example
intocertbot.env
and update with your domain(s) (subliiime.com
) and email addressUpdate
sublime.env
with your new domain + specify HTTPS. For example:(sudo) LETSENCRYPT_ENV=certbot.env docker compose --profile letsencrypt up
(sudo) LETSENCRYPT_ENV=certbot.env docker compose --profile letsencrypt up -d
h/t to the @thinkst team - lots of inspiration from https://github.com/thinkst/canarytokens-docker
Considerations
update-and-run.sh
/ auto-updates. How should we handle this? Perhaps a flag insublime.env
to indicate that it should usedocker-compose-letsencrypt.yml
instead? This is only an issue if the user goes through the normal script first and installs the cron job.TODO in follow-ups
./nginx-letsencrypt/Dockerfile
) and add this build to CI instead (cc @cameron-dunn-sublime let me know what you prefer)