CertSage was designed for people of all ages and experience levels who want an incredibly quick and easy way to acquire Let's Encrypt TLS/SSL certificates. CertSage is especially helpful if you are using a shared hosting plan that does not allow root access, such as GoDaddy or tsoHost shared hosting. It's free, of course!
Upload certsage.txt into the webroot directory of your website (e.g. /public_html) that contains the content that you access when you normally visit http://example.com.
Rename certsage.txt to certsage.php.
Usage
Assuming that your domain name is example.com...
Visit http://example.com/certsage.php.
Copy your password from your password.txt file located in your CertSage data directory, which by default is located in the parent directory of the directory where you installed CertSage. The CertSage data directory and password.txt file are created automatically by CertSage when you visit the CertSage page in your browser if they don't already exist. Should you wish to change your password, simply replace the contents of password.txt with whatever password you wish to use going forward.
Enter the (sub)domain names in the box, one per line, for which you wish to acquire a certificate (e.g. example.com and www.example.com).
Select your certificate key type.
Enter/paste your password into the password box.
(Optional) To ensure that your CertSage installation is working, push the button to acquire a staging (fake) certificate.
If you are confident that your CertSage installation is working, repeat steps 3, 4, and 5 above (if necessary) then push the button to acquire a production (real) certificate.
If you use cPanel, push the button to have CertSage install your production certificate into your cPanel and setup a cron job for you to automatically renew your certificate when needed. If you don't use cPanel, you'll need to install your production certificate using some other method and manage your own certificate renewals.
(Optional) To subscribe to receive important notifications directly from Let's Encrypt, enter the email address(es) in the box, one per line, that you wish to use, then push the Update Contact Information button. To unsubscribe, leave the email address box empty then push the Update Contact Information button.
Using CertSage with Multiple Domain Names Hosted within a Single cPanel Account
WordPress Site Address Update
If your WordPress site starts returning an infinite redirect loop (and thus never loads), follow the instructions in this article to update your site URLs in WordPress:
Nice work! We've discussed it before but it would be great if there was a website for certsage with info and a link to the latest version etc. I know linking in posts here works for getting it in front of some of it's audience, but it would be useful to have a single link we can provide interested parties.
Currently if I google Certsage I mostly get copies of the tool itself, but I'm pretty sure certsage.com is just waiting to happen! Having a site to link to would also let you update donation/sponsoring info, or even offer paid support.
It would also be great if it could check for a new version by itself (even if it's not auto updating) because for the existing audience it's going to be tough for them to know there's a new version out.
Although I've deliberately tried not to host CertSage through GitHub primarily from a layman-accessibility lens, it certainly has crossed my mind many times from a standardization standpoint. Hosting directly from certsage.com is probably the most likely direction from a product standpoint. I've actually been working on the landing page for certsage.com, which will hopefully be coming shortly.
Regardless of what direction I go, I am genuinely grateful for the advice and direction given by all here. It truly means a lot to have such support.
I have hit a potential issues with the CRON job creation in that CertSage correctly creates the renewal CRON job but existing CRON jobs disappear. I am using 123-reg.co.uk (now owned by GoDaddy and using cPanel) shared hosting. I have several domain names and have replicated this problem - when I create a new certificate and save it to cPanel using CertSage version 2.0.0 all existing CRON jobs are deleted and only the new one remains.This includes a CRON job that I created that has nothing to do with CertSage. I can manually create the CRON jobs but that's not the point. Could I be doing something wrong?
1- The source code; where you can build/tag releases for download (and have CI!).
2- A consumer website set up for Github Pages (see https://pages.github.com/) on your domain.
Whenever you have a new release in the source repo, the consumer page can pick it up.
I ran CertSage back-to-back on three domain names with the cron jobs being successfully created for all three domain names. Perhaps a difference in OS? It's a single line in CertSage that creates the cron job:
I just ran; (crontab -l 2>/dev/null; echo "30 15 * * * curl https://$domain/certsage.php") | crontab - from a cPanel terminal and it ran correctly (without deleting the existing CRON entries) so let me do some more testing to see if I can still replicate the problem.
The - is a pseudo file descriptor; it's basically saying "create a new crontab based on the output of the stuff piped into this command".
The stuff before the pipe is: listing the current crontab, and echoing a new entry.
crontab doesn't have a command to add an entry - so the options are to either manually edit the cronfile (which can vary on system and user), or use a trick like this to: display current, append new, overwrite.
OK, so I just ran CertSage for another domain and everything worked perfectly. The new CRON entry was appended to the end of the crontab file as intended without any of the existing entries disappearing. I can't explain why I had problems previously - this was the sixth domain I ran CertSage on and had problems on all of them before. I'll blame 123-reg and cPanel
So thank you again @griffin and sorry for the confusion.
Thank you for reporting this concern. I strongly rely upon these reports to assess the robustness of CertSage. Without them, I'm operating in a bubble.
I am taking a guess that the initial run of that line of script might fail somehow and create a vicious cycle. When testing, I was running commands from the terminal to make the initial modifications to the crontab file. I'll do some more testing from a clean file later today.