Certificate renewal

Please record your expiration somewhere as obviously this won’t manually renew. You could try to renew (just generate a new cert) in like 45 days just to ensure things are stable.

No redirect, but cert looks good.

1 Like

Also, the correct site shows up - right?

I was thinking about it, and I wonder whether I would need to generate the certificates manually, now that the wild card issue has been rectified. I think the script should work from next time onwards. I will confirm when I am up for renewal next time.

Good Night, Jonathan and thanks again!!


Yes, jitsi shows up.

The script doesn’t support DNS challenges, which are required for wildcard certs. Unless you somehow configure a DNS authentication hook for creating/destroying the TXT records, you’ll need to manually renew with new TXT records.

Have a great night!


Yes, I remember that one. Good Night!!

1 Like

Instead of creating a new thread, I have decided to continue over here as this also pertains to renewal and configuration.

One of our domains is throwing the following error,

Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/certbot/renewal.py", line 64, in _reconstitute
renewal_candidate = storage.RenewableCert(full_path, config)
File "/usr/lib/python3/dist-packages/certbot/storage.py", line 420, in init
"file reference".format(self.configfile))
certbot.errors.CertStorageError: renewal config file {} is missing a required file reference
Renewal configuration file /etc/letsencrypt/renewal/comedaddymummy.com.conf is broken. Skipping.

This site was fully functional until recently when we upgraded the system and then, tried to set a permanent redirect from http to https using the control panel of the interface used to manage this domain. Since then, the domain is showing the default page, though there is a sym link to the interface, which should show up. When I did a dry run, I noticed this error, which confirms that the issue pertains to the conf file set up after the permanent redirect debacle.

Any thought on how to fix this issue. I noticed a similar thread here, which led me to reach out again.

1 Like

wait. why do you need a wildcard on your jitsi server?

you can have several certificates and even use a wildcard elsewhere if you have a certificate for some subdomains that the wildcard would cover.

1 Like

Let me clarify. Jitsi needs a standalone server and it is a separate container. Wild card option was chosen taking the nature of the application and the requirements. But, this issue pertains to another container on an apache server.

There is a set of apache based domains which is managed using a primary domain. That domain happens to be the one throwing the error, though two subdomains are fully functional. All the other certificates for other domains in this server are also functional and even this certificate is Ok for now. Only when I renew, it is throwing up that error.

Setting up that permanent redirect without double-checking (I have done this several times before) might have affected the sym link leading to this issue, I think.


That error, it looks complicated.

You still have two different settings for aioexplorer.com (nginx, redirect http -> https) and www.aioexplorer.com (apache just responding on http), be aware of it. If it’s not made on purpose, it’s probably an error.


There is no apache there for Jitsi. But, it is also getting deployed to the default config file, in addition to the site specific config file. This was already discussed yesterday. I am looking into fixing that issue.


By the way, I found a backup file for this domain and recovered the content for the .conf. When I ran a dry run on that one, I did not see the error any more.

Processing /etc/letsencrypt/renewal/######.com.conf

Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for #######
http-01 challenge for #######
Waiting for verification…
Cleaning up challenges

new certificate deployed without reload, fullchain is

This issue has been resolved. However, I still have to figure out recovering the interface.


I think that I got that fixed.

As mentioned, same server name was also added to default file, which resulted in that issue. I believe that I have fixed that error as I see a clean output from Nginx -t.

nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

By the way, has anyone tried adding htpasswd to an Nginx server? For example, something like this seen for apache server, but instead for an Nginx server. I have added necessary code to the aioexplorer.com domain, but it is not working.

Also, the redirect from http to https, non-www domain is not working either (nginx), though all other redirects are working. Any suggestions on this front?


Interface resolved too. It pertained to the host file, which after days of probing, led me to the right solution.

Good Weekend!!


This should help you: Restricting Access with HTTP Basic Authentication | NGINX Plus


Thanks for sharing a reference from Nginx manual. It confirms my understanding.

I already have set up something similar to this one. However, I don’t see the authentication box.

location / {

   auth_basic "Restricted Content";
   auth_basic_user_file /path/to/the/folder/.htpasswd;
   #return 301 $scheme://host$request_uri;   


htpasswd was generated similar to what was shared in the manual. However, I don’t see the authentication box popping up.

Any thoughts on this one.

1 Like

You could be logged in already. Try browsing there with another browser or incognito mode?

1 Like

Good morning, Hope you are having a good weekend!!

Not clear. Are you seeing an authentication box? I tried opening, https://aioexplorer.com, in various devices and it goes to the default landing page, unlike this one which is on apache server and shows an authentication box, https://comedaddymummy.com.

The code that I had shared before for the nginx server should result in an authentication box.

1 Like

No, I don’t see an authentication box. But you do know jitsi meet has some kind of user management, where only approved users can make new rooms?

It probably doesn’t work because there are other location blocks that handle jitsi and they take precedence. Which location block will be followed is kind of an esoteric and ritualistic nginx knowledge: I mean, the docs try to say how it works, but they don’t do it very clearly.


I have also initiated a thread in Jitsi in this regard. As per some developers, it should be feasible.

Yes, there is another internal way for user management. However, this is simpler with more internal control, while piecing together other things in our case.

Good week!!

1 Like

Finally, got the htpasswd working on the nginx server. Thanks to all those who participated in this part of the discussion.

1 Like