- Fully-automated certificate renewals in cPanel
Congratulations making CertSage a fully automated client.
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.
that domain is already bought by someone (from godaddy with whois privacy option).. hope it's griffin himself?
This can all be done with Github as well; both as a repo and as a "project page".
It is me. ![]()
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. ![]()
GitHub pages is quite powerful, if one finds proper documentation for github actions and their apis.
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?
You can create 2 repos on GitHub:
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.
Hmm... ![]()
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:
(crontab -l 2>/dev/null; echo "30 15 * * * curl https://$domain/certsage.php") | crontab -
I'm running
cPanel 118.0.13
PHP version: 8.1.29
on a Linux cloud server.
What does crontab - mean after the pipe?
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.
It overwrites the crontab file.
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.
I just ran the following commands, resulting in three correct cron entries being created:
crontab -r(crontab -l 2>/dev/null; echo "30 15 * * * curl https://griffin.software/certsage.php") | crontab -(crontab -l 2>/dev/null; echo "30 15 * * * curl https://certsage.com/certsage.php") | crontab -(crontab -l 2>/dev/null; echo "30 15 * * * curl https://cloakanddagger.com/certsage.php") | crontab -crontab -l
30 15 * * * curl https://griffin.software/certsage.php
30 15 * * * curl https://certsage.com/certsage.php
30 15 * * * curl https://cloakanddagger.com/certsage.php
I then:
- Ran
crontab -r - Deleted the
/CertSage/autorenew.txtfiles forgriffin.software,certsage.com, andcloakanddagger.com - Used CertSage to install the production certificates of
griffin.software,certsage.com, andcloakanddagger.com - Ran
crontab -l
30 15 * * * curl https://griffin.software/certsage.php
30 15 * * * curl https://certsage.com/certsage.php
30 15 * * * curl https://cloakanddagger.com/certsage.php
This proves that CertSage is working properly on my cPanel host.
Perhaps your cron file might have originally been malformed? ![]()