Certificate renewal

Help
61

I usually do that for third-party situations where the hosting provider and the domain registrar are not the same. But, now from this experience, I will certainly keep that as an option as well.

By the way, I ran the script now and it was successful. I guess adding the wild card option manually before might have helped now.

root@jitsi:####### ./inst*

This script will:

  • Need a working DNS record pointing to this machine(for domain aioexplorer.com)
  • Download certbot-auto from https://dl.eff.org to /usr/local/sbin
  • Install additional dependencies in order to request Let’s Encrypt certificate
  • If running with jetty serving web content, will stop Jitsi Videobridge
  • Configure and reload nginx or apache2, whichever is used
  • Configure the coturn server to use Let’s Encrypt certificate and add required deploy hooks
  • Add command in weekly cron job to renew certificates regularly

You need to agree to the ACME server’s Subscriber Agreement (https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf)
by providing an email address for important account notifications
############
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Running deploy-hook command: /etc/letsencrypt/renewal-hooks/deploy/0000-coturn-certbot-deploy.sh
Output from deploy-hook command 0000-coturn-certbot-deploy.sh:
Configuring turnserver

IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at:
    /path/to/the/folder/fullchain.pem
    Your key file has been saved at:
    /path/to/folder/privkey.pem
    Your cert will expire on 2020-11-10. 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”
2 Likes
62

I concur it worked. :laughing: I did notice it redirects from non-www to www. Hope that’s OK.

Screenshot_20200812-174345_Samsung Internet
Screenshot_20200812-174345_Samsung Internet1440×3040 497 KB

1 Like
63

By the way, the REASON that it worked is because you already satisfied the manual DNS challenges so you don’t need to reverify for 30 days to get new certs. You’ll need to complete the DNS challenges AGAIN when you renew (unless you can find an automated way to create/destroy them through certbot’s “hooks”).

64

I’m also getting this after I clear my cache and go directly to your non-www. It’s at least the same certificate (but you may have multiple copies of this same cert under different configurations).

Screenshot_20200812-174843_Samsung Internet
Screenshot_20200812-174843_Samsung Internet1440×3040 176 KB

1 Like
65

In that case, do I need to manually get the certificate and then run the script for installation? A kind of hybrid case.

Thanks again, Jonathan. Going back and forth helped to look at the issue from different angles to resolve it at the end.

2 Likes
66

It’s possible, but not ideal.

67

@9peppe

Finally. Thought you got lost brother.

68

It won't matter, default is just a name to nginx. What matters is the order in which those files get included, and whether any of them contain a listen something default_server; directive.

1 Like
69

Primary server name is www.aioexplorer.com.

This might be due to the manual installation leading to different options and the non-www might be still deploying to the default site.

I have set a redirect from @ to www, which redirects as you confirmed. However, the non-www site still needs to be resolved. But, we have come a long way and the good thing is the site is functional and the SSL is working for at least the fqdn. For a while today, neither was working.

1 Like
70

yes, I found that experimentally by changing to default1 and removing the file, with both leading to errors.

71

One thought: What would happen if I were to add aioexplorer.com to the server name list and then run the script again? Would that address the issue with the non-www site?

72

@skidambi75 @9peppe
To recap, we did a kludge:

  1. Manual DNS-based certonly wildcard cert using certbot just to get the cert issued.
  2. Run the built-in jitsi Let’s Encrypt script that reissues the same cert with NO challenges (due to previous DNS verification) AND correctly installs the cert.
2 Likes
73

I'm honestly not sure why there are two different sets of content configured. There should be only one content with a permanent (301) redirect from @ to www (or vice versa).

74

It looks like I have fixed the issue for the non-www site as well by adding the @ domain to the server name list.

Jonathan, yes. It was a hybrid solution and the inclusion of all relevant domain names part of the server name list appears to capture the SSL for all related domains.

1 Like
75

I do have a permanent redirect, but that is not appearing to address the SSL for the non-www site.

1 Like
76

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.

77

No redirect, but cert looks good.

Screenshot_20200812-182023_Samsung Internet
Screenshot_20200812-182023_Samsung Internet1440×3040 492 KB

1 Like
78

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!!

2 Likes
79

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!

2 Likes
80

Yes, I remember that one. Good Night!!

1 Like