Letsencrypt certificate renewal error

see Lets Encrypt won't renew TLS certificates with Jitsi Nginx config

It is already 128. I already checked that one. Thanks for sharing.

GNU nano 4.8 xxxx.com.conf
server_names_hash_bucket_size 128;

server {
listen 80;
listen [::]:80;

Possibly yet another bug in Certbot. Anyway I noticed that you have already a certificate so theoretically you should only run with renew. However when something goes wrong people usually do all sort of things and break their existing configuration.
Your last attempt was done with webroot; if you run without webroot (second attempt) that’s because certbot should setup the web server config; however if you use webroot it is up to you to setup the webserver. It’s not coherent to run both options, so it’s to be expected that the attempt with webroot fails because nothing is listening.

I usually utilize the shell script to renew the certificates, which works fine. However, when I ran this one, I am getting a message that the certificate is not yet due for renewal. I could leave it as it is and the cron job part of the shell script in place might address the renewal part when it is due for renewal. However, with email notifications from Letsencrypt about upcoming renewal, along with prior odd experience where an application was not renewed on time leading to challenges made me try the other commands to wrap up the renewal process rather than waiting until the due date. These are commands that were tried before to renew and some also recommended in other forums.

Here is one forum which discusses a similar issue:

Yes your certificate is expiring in 10 days it’s not correct that you get the message that it’s not due for renewal; normally it is 30 days before expiration date. You should have received error messages from your crontab. Anyway you can restart the thing again manually but you have to pick a method, either nginx (try to remove your server_names_hash_bucket_size instruction then) or webroot (in this case create a http section for letsencrypt in the nginx config)

Output from the shell script is what I meant. When it comes to letsencrypt notifications, yes, I have been getting it for some time now.

I just need a clarification. What should I expect from running this script,

As per the output that I see running this script, the certificate is not up for renewal today, which is correct. Should I feel comfortable running this script right when the SSL expires?

I also don’t want to make it any more complicated than necessary. It would help to know the recommended method to renew certificates for Jitsi-meet?

obviously the official way is the one displayed by the install script, running the cron job. If you want to run the cron job manually, it’s just

/usr/bin/certbot renew >> /var/log/le-renew.log

run with sudo of course, and examine the le-renew.log.

if you want to check if things are as it should be, you should run (after launching renewal):

openssl x509 -in /etc/letsencrypt/live/yourdomain.yourtld/cert.pem -text | grep After

the expiration date displayed should be the same displayed by your web server when you access it with a browser and examine the certificate. If it’s not the same, the certificate has been renewed but it’s not in your configuration.

Note that the LetsEncrypt emails can be misleading if you have changed your domains, in this case you get warning mails for the old configuration, you can dismiss them and consider only the emails for your new configuration.

@gpatel-fr: Thanks again for your clarification. Yes, this command is saved as a script as well. That was one of the other tried ones.

I ran this again and the error repeated. Any suggestions? I have also reached out to Letsencrypt in this regard.

/usr/bin/certbot renew >> /var/log/le-renew.log (already signed in as root)

Type: unauthorized
Detail: Invalid response from
[#######3]: “\n\n404 Not

Not Found


To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.

If I run the script, I don’t see any such error, though not renewing.

That’s the right idea.
On the Let’sEncrypt forum the first thing asked is to reveal the domain. This is necessary because lot of people use preconfigured scripts that are making it easy to setup a first domain. And then they want to add another. They begin to make changes without understanding how it works really. They succeed. And then the renewal of the initial domain fails because the initial configuration has been removed by the attempt to create a second domain. Unvariably they forget to talk about their changes and if the failing domain is not known there is no way to find out about the second and so to understand what happened.

Thanks for seconding my thought-process, @gpatel-fr.

I already initiated a thread over there concurrently and am trying to address the issue. Here is the link from there:

I forgot to include a thread from here that points out issues from 20.0.4 where you have also participated. I also tried the suggestions put forth over in that thread for this update.

I also tried the following to see whether that helps as well, which did not.

Most of these commands were tried prior to sharing my concern over here.

well the jitsi-meet script is intended for simple use of people wanting to install a single user on a dedicated domain. You should not use it if you manage several domains IMO.
And please when you are pasting config files or script output on a Discourse forum (that’s the name of the software you use to post here), use the 3 backticks trick: enter the 3 backticks ``` at the beginning of a new line, and redo the same after having pasted it. If not, data is formatted automatically by the markup engine of Discourse and it’s awful to read.

Thanks for the three backticks trick. I usually resolve issues by myself or within our team and don’t come to these forums much. As this one pertains to a third-party platform, which I don’t have control over, I am participating here. This trick would certainly come in handy and will remember that.

Yes, I know what a Discourse is.

Coming to the server and Jitsi, Jitsi is on its own in a separate container and is the only one on Nginx server. Knowing the server need for Jitsi, we did not mix it with other applications.

does it mean that you have some proxy on the physical server ?


● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)

in this case I have a very similar config, a physical server with nginx and a container with the jitsi nginx. However I don’t use the jitsi-meet script at all, all certificates matters are handled at the physical nginx level. And I have disabled TLS at jitsi level.

May I know how exactly you did that? I already shared different things that were already tried out. How is that different than what I have done until now? Do you have 20.0.4 too?

By the way, our site is, https://aioexplorer.com.

May I know what is yours?

Physical is Ubuntu 16.04
Container is 20.04
forwarding is done like that:

server {
    listen 443 ssl http2;
(... hideous nginx stuff censored...)
    location / {
        auth_basic off;
        proxy_pass http://jitsitest:80;

I have another block for http (looking back again at it I am a bit ashamed at it and a bit surprised that it works)

server {
  listen *:80 ;
  listen [::]:80;
(... hideous nginx stuff censored...)
  include /etc/nginx/snippets/letsencrypt.conf;
  location / {
            return 301 https://$host$request_uri;

the letsencript snippet:

location ^~ /.well-known/acme-challenge/ {
	default_type "text/plain";
	root /var/www/letsencrypt;

it’s a snippet because well I have several other servers.
I have a let’s encrypt container whose role in life is to populate the /var/ww/letsencrypt with the appropriate certificate. It’s a container because my strong principle is that a physical server should only have standard software (no ppa no specific stuff so that it can be installed from the hoster template in less than 15 minutes) and at the time only certbot-auto was available for ubuntu 16.04, so Let’sEncrypt software is confined to it’s container.

and finally on the jitsi meet front I have 2 jitsi containers, one for stable, one for unstable, and on each I have butchered the beautiful damenchian configuration by basically deleting everything from the server name in the http block up to the root /usr/share/jitsi-meet; in the https block. Both lines referred here are kept in the config and not deleted.

The jitsi-meet letsencrypt script is here but unused. I don’t intend to ever use it. The turn server is here but unused and I intent do use it one day.

So there, hope it answer your query about my odd habits :slight_smile:

Let me be clear. This is your .conf file, right? Do you imply that the settings in place inside .conf file would automatically renew the certificates?

The reason for this question is that this appears to be a normal server process of setting up a .conf file for Jitsi in a Nginx server. As I have not played around with different types of servers for Jitsi and the settings for some time, this is something that I considered as default and it is already there in the .conf file. As mentioned, our site is live now.

If this were the case, according to your post, I don’t have to worry about renewing the certificate and that should be taken care of. Am I right in my understanding?

With the support of Letsencrypt community, I could manually generate the new certificate. However, it appears that it is getting deployed to the default config file. Any suggestions on the right way to set the letsencrypt SSL certificates installed on the site would be appreciated.

In other words, I am looking to select the right options after executing the following command to install the issued renewed certificates:
certbot install -d ######## -d *.#####

It appears that this installation is getting deployed to the default option rather than the domain of interest leading to the default Nginx file.

@gpatel-fr: Now, the certificates for both the fqdn and non-www sites are functional.
There was some issue with the wild card set up, which forced manual addition of the certificate. Still there were issues to be addressed and after spending entire day with a fellow Letsencrypt community member, I was able to resolve the issue.

For more details and if interested, you could scan this communication: