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 shared hosting. It's free, of course!
Upload certsage.txt to the webroot directory of your website (often something like public_html) that contains the content that you access when you visit http://example.com.
Rename certsage.txt to certsage.php.
If you are hosting multiple websites on a single webserver, you will need a copy of certsage.php in the webroot directory of each of your websites.
Visit http://example.com/certsage.php to acquire your certificate. Most people will want to enter example.com and www.example.com as their domain names.
cPanel Certificate Installation
Open cPanel in your web browser.
Scroll to the FILES section.
Click on File Manager (which should open in a new tab).
Open the CertSage folder.
Click on the certificate.crt file.
Click Edit.
Copy the first certificate in the file including its header and footer.
Click Close.
Switch back to the cPanel tab.
Scroll to the SECURITY section.
Click on SSL/TLS (not SSL/TLS Status).
Scroll to the INSTALL AND MANAGE SSL FOR YOUR SITE (HTTPS) section.
Click on Manage SSL sites.
Scroll to the Domain section.
Select your domain name in the drop-down list.
Paste your certificate in the Certificate box.
Switch back to the File Manager tab.
Click on the certificate.key file.
Click Edit.
Copy the private key in the file including its header and footer.
While possible, this would require decoding the certificate and comparing to the request. Can be done, but would add a significant amount of logic to prevent a manually-driven issue. Since at present the user must manually generate then install the certificate, it is unlikely that a user would want to expend the effort to rate limit themselves. Unlike the workflow of many/most other ACME clients, there is a definitive point in the CertSage process where the user necessarily recognizes the successful acquisition of the certificate, making it highly unlikely that the user will immediately attempt to acquire another certificate for installation. If a user wants to obsessively install a new certificate six times per week, that same user will likely just circumvent any prevention mechanism.
On another note, considering that the staging and production certificates and keys overwrite one another, logic would be required to distinguish between a staging and production certificate, which is no small feat without hardcoding the names of the signing intermediates. Could (and probably should) disable the saving of staging certificates to circumvent this issue. Think I'll do that today to prevent installation of staging certificates and keys.
As a note for future development efforts, if a guard were put in place to prevent early renewal, it would either need to be very basic with an easy way to ignore or it would be necessary to save non-duplicate certificates separately, verify cert-key pairs, and check for revocation to ensure that an existing certificate viably satisfies the user's current request.
Staging certificates and their private keys are no longer saved. This prevents them from accidentally being installed. It also consequently prevents the latest production certificate and its private key from being overwritten by a staging certificate and its private key.
I'd love to offer that. While CertSage itself is very reliable and I'm happy to address any troubles encountered within the CertSage software itself, the myriad environments and circumstances in which CertSage can be utilized make it impossible to make such a guarantee. I can say that my development of CertSage was undertaken entirely on Samsung smartphones and thoroughly tested on my own, stock GoDaddy cPanel shared hosting instances, so GoDaddy users at the very least have a fully blazed path to travel. There has also been testing on other hosting and platforms as well with generally complete success. A few hiccups have happened along the way with this release addressing several of them.
That said... if any of the usual suspects around here are in the Denver area and want to get together, the first coffee is on me.
P.S. - Installing CertSage should take less than 30 seconds. Acquiring a certificate covering two domain names should take less than 10 seconds. My personal best time for running through the exact cPanel Certificate Installation instructions above is about 45 seconds. All of these times are when using a smartphone.
Wish I had known before they closed. Hacienda Colorado has struggled to achieve their former quality and variety. La Loma has good quality, but is too mild for my taste.
On an odd note, the infamous Casa Bonita was bought by the creators of South Park. Have no idea what that's about yet.
Just FYI for anyone using GoDaddy SHARED hosting where you have a parent domain with one IP address for all domains (or anyone else with a similar file structure as below), please note the following to secure your site!
CertSage (this is where the parent domain cert is stored)
public_html (webroot for the PARENT domain)
childdomain1 (webroot for childdomain1)
childdomain2 (webroot for childdomain2)
childdomain3 (webroot for childdomain3)
childdomain4 (webroot for childdomain4)
CertSage (this is where the child domain certs are stored as they're created)
Note that for the child domains, CertSage will create the directory (and associated files) in the webroot of the parent domain, leaving the cert vulnerable and seriously compromising security as all files are readable.
You can secure your site in two ways:
Delete the CertSage directory and its files once your cert install is complete. (When you install a certificate and its private key, cPanel keeps its own copy of them internally (under ssl in the root folder), so there's no need to keep separate copies (or any copies for that matter) of acquired certificates once they're installed into cPanel.)
More complicated way if you want the save your certs and/or eliminate any window for malicious intent:
Before running CertSage, edit the certsage.php files for each child domain thusly:
A) Edit line 18 to change the $dataDirectory variable from " ../CertSage " to " ../../CertSage " . This will cause all of the certsage.php scripts to securely use the same data directory one level below the webroot of the parent domain.
B) If you want to keep copies and not overwrite the certs for your parent domain in the CertSage folder, edit lines 636 and 640 of certsage.php to name the two files as you please.
Example:
a.com could write a.com.crt and a.com.key
b.net could write b.net.crt and b.net.key
c.org could write c.org.crt and c.org.key
The majority of this post is copied and pasted from a reply that @griffin posted on a thread of mine, but I thought I would post it here so anyone else running into this same issue would be able to find it easier! Hope it's acceptable to do so!
Because the child/secondary domains' webroot directories reside inside the public_html folder. Thus, when by default CertSage creates its data directory at "../CertSage", a child/secondary domain of example.com having its webroot directory at "/public_html/example.com" will have its CertSage copy create its data directory at "/public_html/example.com/../CertSage", which simplifies to "/public_html/CertSage", resulting in the private keys inside being accessible via the parent/primary domain from the public internet.
For those wondering why I chose to use the relative ".." rather than an absolute path, PHP in web mode is necessarily provided very little information about its environment to prevent leaking/abusing such information. The PHP script doesn't even know in which directory it resides!
In doing some testing today, I discovered a minor bug on line 742 consisting of an extraneous script closing tag (</script>) in the head section of the HTML document. Said line is an ancient remnant from a prerelease version of CertSage that has no functional impact upon its current operation. I have removed said line for future versions of CertSage.
Even better have a certsage.config file (or certsage.config.php?) file so you can upgrade the certsage script without changing anything else. Time has told me that the number one rule of releasing software is to have a way to update, which is substantially more important that any other feature - the only constant is change
I've been thinking about returning to it. Right now, only the CertSage directory name and location has such a constant, which is the only one most users modify.
While CertSage itself is very reliable and I'm happy to address any troubles encountered within the CertSage software itself, the myriad environments and circumstances in which CertSage can be utilized make it impossible to make such a guarantee. I can say that my development of CertSage was undertaken entirely on Samsung smartphones and thoroughly tested on my own, stock GoDaddy cPanel shared hosting instances, so GoDaddy users at the very least have a fully blazed path to travel. There has also been testing on other hosting and platforms as well with generally complete success. A few hiccups have happened along the way with this release addressing several of them.
