Certificate renewal

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.

2 Likes

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.

2 Likes

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.

2 Likes

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
/path/to/the/folder/fullchain.pem

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

2 Likes

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?

2 Likes

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

Good Weekend!!

2 Likes

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

3 Likes

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.

2 Likes

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

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

1 Like

I renewed the SSL certificate for ammahub.com and the wild card manually and successfully.

  • Congratulations! Your certificate and chain have been saved at:
    /etc/letsencrypt/live/ammahub.com-0002/fullchain.pem
    Your key file has been saved at:
    /etc/letsencrypt/live/ammahub.com-0002/privkey.pem
    Your cert will expire on 2020-11-25. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot
    again. To non-interactively renew all of your certificates, run
    ā€œcertbot renewā€

However, post renewal, the primary domain is taking me to the default ssl configuration and the domain is not working any more. On the positive front, idea.ammahub.com sub-domain is functional, but the SSL is not updated.

Any suggestion on fixing this issue would be appreciated.

1 Like

A quick update. I have brought back the www site functional, though still having issues with the SSL and the non-www site.

Any suggestions would be appreciated to fix the SSL and the non-www site…

Good Weekend!!

1 Like

This suggests that you have several certificates with overlapping coverage and your web server application might not be configured to use the one you expect.

If you run sudo certbot certificates you can see which they are and what they cover.

2 Likes

Thanks, Schoen.

If you meant that there could be more than one certificate for this particular domain, I had created one before and as it was not working. I deleted that certificate and created another one.

When I ran the certificates listing command (which I already checked prior to reaching out) after seeing your message, I found only one certificate for this domain.

Here it is,

Certificate Name: ammahub.com-0002
Domains: ammahub.com *.ammahub.com
Expiry Date: 2020-11-25 22:50:07+00:00 (VALID: 80 days)
Certificate Path: /etc/letsencrypt/live/ammahub.com-0002/fullchain.pem
Private Key Path: /etc/letsencrypt/live/ammahub.com-0002/privkey.pem

For that matter, SearchGiggle.com domain has two certificates and still it is functional.

Certificate Name: searchgiggle.com-0001
Domains: searchgiggle.com www.searchgiggle.com
Expiry Date: 2020-11-09 20:30:31+00:00 (VALID: 64 days)
Certificate Path: /etc/letsencrypt/live/searchgiggle.com-0001/fullchain.pem
Private Key Path: /etc/letsencrypt/live/searchgiggle.com-0001/privkey.pem

Certificate Name: searchgiggle.com
Domains: searchgiggle.com daddu.searchgiggle.com www.searchgiggle.com
Expiry Date: 2020-11-09 20:30:42+00:00 (VALID: 64 days)
Certificate Path: /etc/letsencrypt/live/searchgiggle.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/searchgiggle.com/privkey.pem

Also, if I were to have a wild card certificate, it should cover subdomains - right? I am having the same issue with the subdomain, idea.ammahub.com too.

Note: I have at least 10+ certificates and all are functional except for this one.

1 Like

By the way, I even tried to get a separate certificate for idea.ammahub.com and was not sure what the host value that I need to enter in the text record. For ammahub.com & wild card, I entered host value to be _acme-challenge for both the full domain and the wild card, which worked for verification purposes.

1 Like