CertSage 2.1.0 Release

[griffin]

GitHub - GriffinSoftware/CertSage at v2.1.0

---

• Switched from using PHP shell_exec() to exec() to expand certificate installation compatibility to more hosting providers

[MrDuckHunt]

Hello,
thank you so much for your work.

The certsage.php could be nested inside some directory or is it mandatory to stay on the root one?

I saw that when CertSage is used to install certs on cpanel, automatically add a cronjob to start itself without parameters once a day, i'm not so skilled to read the code, do you check if the script is called by localhost? Or it run anyway?

[griffin]

Welcome to the Let's Encrypt Community!

@MrDuckHunt

The certsage.php could be nested inside some directory or is it mandatory to stay on the root one?

certsage.php must be located in the webroot directory since it creates the challenge directories and files inside the directory in which certsage.php is located.

@MrDuckHunt

I saw that when CertSage is used to install certs on cpanel, automatically add a cronjob to start itself without parameters once a day, i'm not so skilled to read the code, do you check if the script is called by localhost? Or it run anyway?

I'm not exactly clear on what you're asking here. At the end of the first certificate installation, CertSage appends a cron job to the user cron tab file, which is not the system cron tab file.

[MrDuckHunt]

@griffin

certsage.php must be located in the webroot directory since it creates the challenge directories and files inside the directory in which certsage.php is located.

Ok, i was just wandering about it, because can be easily spotted by a crawler if a domain use or not CertSage, that's maybe isn't a problem at all, but sooner or later could be a security flaw.

@griffin

I'm not exactly clear on what you're asking here. At the end of the first certificate installation, CertSage appends a cron job to the user cron tab file, which is not the system cron tab file.

Sorry about that i'm not native english speaker so maybe i could translate something wrong.

What i mean is that, to automate the the renew of the certificate, you add an user cron job that call with curl the https://doma.in/certsage.php without arguments.

So i suppose (sorry but my code reading skill isn't so deep) that if that php page/script is called without arguments, if the certificate is old enough and if it's present the file autorenew.txt it start the renew process without any input.

Do you have implemented some check from where the curl command is invoked?

I mean, if a malicious user put a bot curling your https://certsage.com/certsage.php the php script will run or not?

I know that these could be useless concern, but where there are peoples like you that help others to made internet a better place, there are ten that thinking how to use this as Trojan horse.

[griffin]

@MrDuckHunt

Ok, i was just wandering about it, because can be easily spotted by a crawler if a domain use or not CertSage, that's maybe isn't a problem at all, but sooner or later could be a security flaw.

CertSage generally requires a password to use, so no need to worry about bots/crawlers.

@MrDuckHunt

if that php page/script is called without arguments, if the certificate is old enough and if it's present the file autorenew.txt it start the renew process without any input.

This is true.

@MrDuckHunt

I mean, if a malicious user put a bot curling your https://certsage.com/certsage.php the php script will run or not?

This is expected and part of the design. If a bot/crawler wants to trigger your renewal for you, this is not a problem. The code for checking if it is time to renew is very lightweight, so there's no significant loss in terms of your server's resources if bots/crawlers are hitting certsage.php frequently.

@MrDuckHunt

I know that these could be useless concern, but where there are peoples like you that help others to made internet a better place, there are ten that thinking how to use this as Trojan horse.

I welcome feedback and questions about security. They help me make CertSage better for everyone.

[jamthegent]

Hello. I just used CertSage on my primary domain and two addons, and it works great. I do have a question, however. When I look in the data directory, there is no "account-staging.key" listed. However, there is a "responses" text file. Everything seems to be working, but I just wanted to check with you to make sure. Thanks!

[griffin]

Welcome to the Let's Encrypt Community!

Firstly, thank you for your kind praise.

To assuage your concerns, there would only be an account-staging.key file if you acquired a staging certificate to check your setup. The responses.txt file is simply a log file that's created whenever CertSage communicates with Let's Encrypt's servers.

[jamthegent]

Thanks so much. I appreciate your quick response.

[rossta0825]

I am getting emails that appear to be from my cron job and certsage and seem to be HTML, but are showing as raw HTML code - it seems because there is stuff before the opening HTML tag. They are happening more often than I think certsage should be running so wonder if they are due to bots crawling and triggering certsage to run prematurely?

In any case, I'd like to be able to read what these are about or not receive them.

Here is the start of one of those emails:

% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                Dload  Upload   Total   Spent    Left  Speed

 0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>CertSage</title>
<meta name="description" content="CertSage">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="theme-color" content="#e1b941">
<meta name="referrer" content="origin">
<style>
*
{

[orangepizza]

that sounds like curl saved too verbose result into mail? use -s option to suppress it.

[griffin]

Welcome to the Let's Encrypt Community!

CertSage itself does not send any emails. If you are receiving emails resulting from failed cron jobs curling CertSage, those are being generated from your server. Bots and other external actors would not trigger such emails to you. @orangepizza's suggestion can help reduce the noise, but you'll still want to check why you're receiving these emails at all. You can enable/disable these emails within the interface of your cPanel:

Cron Jobs | cPanel & WHM Documentation

The HTML/CSS you've posted appears to just be the processed output of certsage.php, which is what you'd expect to see when curling CertSage. I have added some markdown to your post above to make it visible here.