Add-On Domain Handling - CertSage / GoDaddy / cPanel

Help
1

Hi folks, mostly a CertSage question here.

I'm on an old-ish GoDaddy Web Hosting Deluxe plan with no SSL considerations short of paying literally as much as the hosting plan itself, or more. I just pulled the trigger on setting up CertSage last night. It went painlessly, but a couple of things concern me a little bit going forward.

Prerequisites:

My "primary domain" is hannambnb.com. I have a few add-on domains right now. Vanity sites bytebrothers.org and rectaltronics.com, and a soon to be important again site rebekahcourt.com. I might eventually add a few more in my {cough} copious free time.

Server according to cPanel (126.0 build 37) is Apache 2.4.65 on x86 linux. cPanel mentions SSH but this is a cheap package on a shared server so "root" isn't likely. :slight_smile: CertSage version is 3.0.2.

Background:

File certsage.php initially uploaded into:
/home/*charactersalad*/public_html

The directories for my add-on domains are under /home/*charactersalad*/public_html, so, /home/*charactersalad*/public_html/bytebrothers.org, etc.

I ran *domain*/certsage.php, as expected it created its CertSage directory in /home/*charactersalad*/, and when it was finished it set up the relevant entries in the SSL/TLS Status module in cPanel, created a cron job "curl https://hannambnb.com/certsage.php " and SSL worked perfectly. AWESOME.

I then followed up by uploading certsage.php into one of the add-on domains:
/home/*charactersalad*/public_html/bytebrothers.org

As expected when running the web page it created the CertSage directory in /home/*charactersalad*/public_html, added the entries in the SSL/TLS module and created a cron job "curl https://bytebrothers.org/certsage.php ". Makes sense so far.

Concerns:

Then I did the same thing for rectaltronics.com and rebekahcourt.com. Which is when I suddenly realized the upcoming location conflict for the CertSage directory. It ran using the same password from /home/*charactersalad*/public_html/CertSage, correctly created the SSL/TLS module entries, but no new cron jobs were created.

SSL works fine on the primary domain and all three add-on domains but I'm wondering how this is going to go at renewal time.

I was kind of expecting two more cron jobs?

Thanks everyone for any input!

1 Like
2

Welcome to the Let's Encrypt Community! :slightly_smiling_face:

I'm the author of CertSage.

I think you'll find this very helpful:

4 Likes
3

Pleased to "meet" you Griffin and thank you very much for the quick response. Can't get much more authoritative then the author, eh... :wink:

Now that I rushed in and, naturally, screwed up a little bit, how best to fix it? I'm perfectly comfortable editing certsage.php and fishing around in cPanel File Manager. I just need to remember to not "upgrade" certsage.php without planning.

Should I delete the bytebrothers cron job, remove the CertSage directory and contents under public_html and remove the certs for all three add-ons, then run the appropriately modified certsage.php from each add-on domain? Or is removing the three certs unnecessary? Anything else come to mind immediately??

Thanks again!!! And many MANY MANY thanks.

2 Likes
4

FYI because I like to make things occasionally too complicated, but at least flexible so I don't have to edit this for every add-on domain, I am choosing to do this:

$dataDirectory = "../../CertSage." . $_SERVER["SERVER_NAME"];

1 Like
5

Happy to help. :slightly_smiling_face:

The certs that are already installed into cPanel are fine for website operations, but you'll need certs in your CertSage.x data directories for them to be read and renewed since CertSage uses the cert in its own data directory rather than extracting it out of cPanel. Your naming plan using the server variable should work and is something I think I'll consider doing myself going forward. For adjusting your setup, you'll need to acquire production certs into the various CertSage.x data directories (one cert per directory). Remember to use the test (staging) in CertSage if you want to check your setup before acquiring production certs. You can manually create/copy the autorenew.txt file for each data directory then create/manage the cron jobs yourself in cPanel. The cron jobs only serve to load certsage.php once per day, but feel free to adjust that as you wish. They don't do anything special. CertSage checks for the renewal of the certificate in its assigned data directory every time it loads, regardless of how, so you, another visitor, a cronjob, a search bot, or any number of other sources could cause certsage.php to load and thus check for a renewal. Based upon your responses above, I have good confidence that you'll put together a great setup.

4 Likes
6

Thank you Griffin, I'll make the add-on domains my project tomorrow night.

In cautious testing the server variable appears to work fine, at least for me. I can't say if it will be reliable with other hosts.

I am tempted to try to figure out a way to determine in the script whether it is running from the primary domain or an add-on, but I might just be getting silly.

3 Likes
7

Excellent! Let me know how things go. :slightly_smiling_face:

If you have any luck, please let me know what you did.

3 Likes
8

I'm fiddling around this morning and here's a couple of thoughts...

The server variable returns what you called the page with, so if you use domain.tld/certsage.php then it gives you domain.tld. If you browse the page via www.domain.tld/certsage.php then it gives you www.domain.tld. As a result some filtering may be necessary for the masses. I always use naked domain names so for me it's no big deal but making your code universally usable also needs to account for stuff like domain.co.uk, etc.

As for figuring out if the primary domain or an add-on domain, getcwd() returns a full (ehrm virtual) path for me. For example:
/home/charactersalad/public_html
versus
/home/charactersalad/public_html/rectaltronics.com

Easiest (for my hosting at least) is to check if "public_html" is the last element (using basename() I guess). Or I could check if the domain name is the last element or is incorporated into the string. I'll think about it a little today. Not sure which would be more compatible for the masses, if either. But at least for me it equates to having one script instead of two, if that winds up being important to me versus just being an intellectual exercise.

4 Likes
9

Good findings. Things to ponder. :thinking:

4 Likes
10

For now I'm going with:

if (basename(getcwd()) == "public_html") {
  $dataDirectory = "../CertSage";
} else {
  $dataDirectory = "../../CertSage." . $_SERVER["SERVER_NAME"];
}

Gonna sit on it today and fire it off tonight.

I see a few other people are reading this. If anyone else has thoughts, don't be shy.

EDIT: For readers who aren't up to speed on PHP, this makes the usual CertSage folder for the primary domain, above the public_html folder not in it, then in the same place makes CertSage.domain.name folders for each add-on domain when certsage.php runs from the respective home folders.

So when you're done you should see:

/home/cpanel_id/CertSage
/home/cpanel_id/CertSage.domain1.com
/home/cpanel_id/CertSage.domain2.org

etc...

For this to work predictably for you, you need to be consistent with how you use the certsage.php web page on your websites. Either use www or use the "naked" domain name without using www, but be consistent.

If you use www.domain.com/certsage.php you'll wind up with a folder named /home/cpanel_id/CertSage.www.domain1.com. Which is not TEOTWAWKI, but do understand that if you use the naked domain name subsequently, the script will be looking for /home/cpanel_id/CertSage.domain1.com (without the www.)

I could probably fix that to remove www without much effort, if someone is nervous and desperate.

My thanks to Griffin and to Let's Encrypt and to everyone else who contributes here.

2 Likes
11

Seems pretty reasonable to me. :slightly_smiling_face:

3 Likes
12

Thanks Griffin.

Iinterestingly when a few days ago I cloned one website into another domain (kingdavidvilla, which is now a backup for hannambnb while our business pivots a bit), got it settled down and ran the php script for it, and I got a working SSL and a cron job for kingdavidvilla but the other four disappeared. Strange. Nothing obvious in the logs.

2 Likes
13

Yeah. The cron job file updates aren't very reliable for some reason and tend to overwrite existing things. This is one of the reasons why after the autorenew.txt file gets created that CertSage doesn't do anything with the cron jobs in terms of maintenance. Feel free to manually add the others back in and manage the cron jobs as you see fit. Please reference the other things about the cron jobs I've mentioned in this thread. You could even replace all of the cron jobs with a single cron job that calls a single script that hits each domain name's certsage.php. When you add a new domain name you'd just manually update that script and copy the autorenew.txt over into the new CertSage data directory to prevent CertSage from creating a new cron job.

3 Likes
14

Thanks Griffin. Re the other things you mentioned about the cron jobs and their purpose, I meant to ask you something before but I got distracted...

Would a crawler really go looking for certsage.php? What other circumstances do you imagine would load it besides myself or another admin loading it?

Suddenly I'm missing the days of being able to go parsing httpd.log manually. :slight_smile:

1 Like
15

If you search an engine for certsage.php you'll find more than a few results. :slightly_smiling_face:

CertSage is common enough now to be logically paired with cPanel instances.

2 Likes
16

I find that just slightly frightening. Thanks!!!

1 Like
17

I guess the Grand Experiment would be to see what happens at expiration time. :slight_smile:

Speaking of which, wouldn't a weekly cron job be more friendly to the cert servers??

1 Like
18

No. The client won't send any requests to the servers if the certificates are not within the renewal window.

4 Likes
19

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.