How to renew Let's Encrypt?

[Yomi_Tsuku]

I got the warning email but don’t know how to renew it.

[robbyoconnor]

There should be a cronjob that does it automatically for you.

Also:

Set up HTTPS support with Let's Encrypt

This is a guide for enabling HTTPS on an existing Discourse installation using Let’s Encrypt. It assumes prior installation without HTTPS enabled. Required user level: System Administrator This guide is only for existing installs where HTTPS is not enabled. Following the official setup guide automatically enables HTTPS by default. So you’d like to add https to your Discourse absolutely free, courtesy of our friends at Let’s Encrypt? I…

[gigperformer (David Jameson)]

Our forum is down (i.e. blocked by Safari) due to this certificate having expired today. What’s the cron job? Can I run it manually?

[robbyoconnor]

It should happen automatically for you if you are running via Docker. I have never needed to manually renew mine.

[gigperformer (David Jameson)]

Thanks, Robby. The problem was due to the fact that I was blocking port 80 (seemed like a good idea from a security perspective) and didn’t realize that LetsEncrypt used port 80

[supermathie (Michael Brown)]

Yep - outright blocking port 80 is usually a bad idea:

• people trying to get to the http side won’t be able to connect and thus won’t get the redirect to https
• let’s encrypt uses http to verify by necessity

[Stephen]

Let’s Encrypt needs to expose itself on :80 because verification of the DNS name is done via HTTP.

You want to leave it open anyhow as Discourse will take care of any redirection from :80 to 443 for clients who try to visit the insecure URL. The same instance of nginx is listening on :80 and :443 so there’s nothing to be gained by shutting down that port, and as you’ve already learned there’s quite a lot to lose.

[gigperformer (David Jameson)]

@Stephen

Let’s Encrypt needs to expose itself on :80 because verification of the DNS name is done via HTTP.

You want to leave it open anyhow as Discourse will take care of any redirection from :80 to 443 for clients who try to visit the insecure URL.

Ah yes, if I’d known then what I had to later go off and learn to figure out why it didn’t work…

The thing is, I wasn’t using port 443 either. Externally, I was using a port in the high 10,000s and my firewall was redirecting those incoming requests to port 443.

Sigh

[Stephen]

That’s always going to be the risk when you deviate from the recommended configuration.

There’s a lot of knowledge here on meta though - maybe next time you want to make those kinds of changes you can run them by us first and we can help you understand any implications and the safest way to make them.

One added benefit to the above is that anyone searching to do the same down the line will also see the advice when(if) they search.

[robbyoconnor]

@gigperformer

Thanks, Robby. The problem was due to the fact that I was blocking port 80 (seemed like a good idea from a security perspective) and didn’t realize that LetsEncrypt used port 80

You should keep port 80 open and do a redirect to HTTPS. This is how most of the web handles things.

[gigperformer (David Jameson)]

Thank you - but in general I don’t want to keep port 80 open — as I mentioned above, I don’t even expose port 443 publicly.
I guess I’ll just have to temporarily open it every few months, manually update LetsEncrypt and then close it again or else use the DNS challenge.

[Stephen]

The only difference between 80 and 443 is the certificate. Unless you don’t trust nginx it’s fine to leave open.

[joao_pimentel_ferrei (João Pimentel Ferreira)]

@robbyoconnor

이를 자동으로 수행하는 cronjob이 있어야 합니다.

어떤 cronjob을 말씀하시는 건가요? 제가 수동으로 추가해야 하는 건가요, 아니면 Discourse를 설치할 때 이미 설정되어 있는 건가요? cronjob에 어떤 명령어를 추가해야 하나요? certbot renew가 Discourse 인증서에서 실패하고 있기 때문이거든요.

[sedget]

저도 같은 문제가 있습니다. 제 인증서는 12월 20일에 만료되었습니다.