Action required: Let's Encrypt certificate renewals


As many others I received the following email:


Action is required to prevent your Let's Encrypt certificate renewals from breaking.

Your Let’s Encrypt client used ACME TLS-SNI-01 domain validation to issue a certificate in the past 60 days.

TLS-SNI-01 validation is reaching end-of-life and will stop working on February 13th, 2019.

You need to update your ACME client to use an alternative validation method (HTTP-01, DNS-01 or TLS-ALPN-01) before this date or your certificate renewals will break and existing certificates will start to expire.

If you need help updating your ACME client, please open a new topic in the Help category of the Let's Encrypt community forum:

Help - Let's Encrypt Community Support

Please answer all of the questions in the topic template so we can help you.

For more information about the TLS-SNI-01 end-of-life please see our API announcement:

March 13, 2019: End-of-Life for All TLS-SNI-01 Validation Support

Thank you,
Let's Encrypt Staff

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: Haven't run anything yet as I am unsure what to do.

It produced this output: n/a

My web server is (include version): Apache 2.2

The operating system my web server runs on is (include version): Synology DSM 6.2.1

My hosting provider, if applicable, is: n/a

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No

Synology DSM’s built-in support for Let’s Encrypt has only ever used the HTTP challenge (not TLS-SNI). Source:

So, if you have received the TLS-SNI email, then it means you have been creating certificates some other way.

For example, using Certbot.

Do you remember how you created the certificate for that domain initially?

Due to the fact that I didn’t want port 80 to be opened permanently I had to renew the certificate manually every 3 months I think. This meant I had to ssh in DSM and issue the following command:

/usr/syno/sbin/syno-letsencrypt renew-all

That was all I did each time.

Are you certain that this is the only domain that you have registered with Let’s Encrypt?

You shouldn’t have received this email if you had only been using Synology to renew.

1 Like

Yes I am certain. That’s the only domain registered with let’s encrypt. No others.

Hi @polanskiman

then you have to switch to dns-01 - validation.

1 Like


And how to do that with DSM?


This [FQDN] domain doesn't resolve to an IP.
So all IP based authentications are not possible for it (like HTTP & HTTPS).
Which leaves only DNS authentication for such a name.

If you haven't done DNS authentication before on DSM, then you need to get that "how to" information from the web or Synology.

[I don't think you will find such a device specific setting (or "how to") in this forum - but you are free to look]

[EDIT - if you do find "how to" do that, maybe you could post a link to it here ]

Apologies. Realized I made a mistake in the domain. Here is the correct one:

OK, then you need to ensure IPv4:80 can reach your server and your server is responding to those requests.
Connecting to (||:80… failed: Connection timed out.
Right now it seems that IPv4:80 is unreachable or unresponsive.
This could be…

  • ISP blocking port 80 inbound.
  • Firewall (appliance or local software) blocking port 80 inbound (or Geo-Location blocking).
  • (DSM) Web server NOT listening on port 80.

Or for some other reason(s)…

As I mentioned earlier port 80 is actually blocked on purpose on DSM for that subdomain to restrict access. I have opened it now. How is that going to resolve the issue regarding the email I received from Let’s Encrypt?

The email merely states that TLS renewals will cease come Feb 13.
So you should be prepared to renew via some other method (primarily HTTP = simplest).
If you can script the opening/closing of port 80, then you might be able to automate renewals via HTTP.
If you need to do this manually, then you will need to set yourself a reoccurring reminder (and do it manually).

Port 80 is actually blocked at the routeur level not from DSM as we need port 80 opened locally. The point is that I didn’t want port 80 opened to the world on a permanent basis.

I found this guide on Github about using DNS-01 protocol:

Not sure what it is worth though.

Well it seems your choices are very limited.
Do you have any Internet facing IP that allows port 80 in?

Yes we do. The main domain but it is hosted elsewhere. The one with the certificate is the sub-domain. So I guess that wont help.

What about the DNS-01 protocol mentioned above?

The DNS-01 protocol link seems like a hack.
Which may not survive a version upgrade.
I would much prefer anything that is built-in to DSM (as a first choice).
So I would go that route first.
Is there anyway to allow port 80 in but route it to another dedicated device?

That said, perhaps you can somehow validate a cert elsewhere (like at that other server) and copy it over securely (every time it renews).

Just thinking about possible alternative solutions…

Thanks for the options.

Yes I rather avoid hacks. It was already annoying to have to open port 80 every time I had to renew the certificate so a hack would be worse as it might not survive a DSM update.

Routing port 80 to another device is not really an option or perhaps to meant routing to a dummy device? But now that I am thinking, would allowing inbound connections on port 80 from specific IP address/range (Lets Encrypt servers) to our NAS be possible? Like this only Let’s Encrypt is allowed through port 80 but other connections would be blocked.

As for validating the certificate remotely I would need to look into it but it does create an additional layer of complexity.

No. Let's Encrypt doesn't publish a specific IP range.

Let's Encrypt only makes requests to the path /.well-known/acme-challenge/ but they can come from any IP address.

Thanks. So what would you suggest I do?


That's why I'm suggesting a "dedicated" device to only handle the inbound port 80 requests.
It would only have two jobs:

  1. handle the LE auth requests (/.well-known/acme-challenge/ - which can be proxied to your real server)
  2. forward all (other) HTTP requests to HTTPS.