CertSage ACME client (version 1.2.0) - easy webpage interface, optimized for cPanel, no commands to type, root not required

I'd love to offer that. :smiley: 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. :slightly_smiling_face:

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.


Thank you that worked well.


I heard that Benny’s closed during the pandemic and will not reopen.

I am so sorry.


Never knew about them. :frowning:

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.


scrub that, I clicked the wrong button


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!

(Thanks to @griffin for answering my questions!)

If your file structure is like this:

  • Root directory for shared hosting user
    • 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:

  1. 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.)
  2. 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.


  • 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!



In what way does this make anything vulnerable?


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.


The following table indicates the lines of certsage.php to modify should you wish to customize file and directory names, locations, and permissions.

Entity Line Number
CertSage directory name and location 018
CertSage directory permissions 285
account.key file name 266
account-staging.key file name 273
account.key and account-staging.key file location 377
account.key and account-staging.key file permissions 379
certificate.crt file name and location 636
certificate.crt file permissions 638
certificate.key file name and location 640
certificate.key file permissions 642
responses.txt file name and location 647 and 686
responses.txt file permissions 649 and 688

Don't you want to make them constants, and put the definition at the beginning of the code with comment: "customize here"?


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 :slight_smile:


I actually had that in the original design. :slightly_smiling_face:

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.


Although one of my primary design rules in designing CertSage is delivery of a single PHP file, I'm thinking that upon execution I can have CertSage create a default version of a configuration file should it not already exist. That would allow setting of a passcode as well, which would prevent unauthorized usage.


UPDATE: Fixed! I didn't realise you meant "-----BEGIN PRIVATE KEY-----" by "header". :woman_facepalming:t2:

Hi @griffin

Amazing little tool - thank you. However, I'm having problems in my cPanel (Tsohost).
When I enter the text from certificate.crt and certificate.key as per your instructions, I see this red warning: "The certificate is not valid." and "The key is invalid." and I am therefore unable to click "Install certificate".

Does the certificate and key look right to you here (screenshot)?

Domain: gigglemugcomedy.com

Extra info: I have previously had a Let's Encrypt certificate on this domain, that has now expired.

Update: I have tried the same process with another domain after uninstalling the previous certificate, and got the same "invalid" problem.


I would probably do this:

  • Define constants at the top of the script, as @bruncsak suggested
  • If there is a certsage.config.php file in the directory as @webprofusion suggested, load/parse that to overwrite the vars. If it doesn't exist, write the vars to it. Also include a version id for the file, so you can detect incompatible changes as your project progresses.

That would give your users portability and stability for their customized configs, and they can just replace the main file.


Usually, there are some "boundries" above and below the certificate and private key, looking like:




for the certificate and the private key usually has:




These boundries are usually mandatory for the software to recognise it as a certificate and private key.

Note that you've posted a (probably large) part of your private key to the entire world wide web in your post. Leaking a private key is reason for revocation of the certificate. Not sure how strict that is for leaking just part of the key, but it might be that all the relevant parts of the key were in the part you've leaked. So strictly speaking you should revoke the certificate, although I'm not sure if CertSage has that capability. @griffin ?


I ballparked some numbers (estimating via the number of base64 lines shown) and the given screenshot (which is still available via the history!) should contain roughly 200 out of ~256 bytes (assuming an RSA-2048 bit key here) of the private key's exponent. Given some time that should be enough to reconstruct the private key fully.

Actually doing this would take some hours (most annoying part being the OCR) and I don't have time for that today, but I definetly recommend revoking that cert - it's no longer safe.


It's way easier to just typ it all over instead of using garbage OCR programs.. :stuck_out_tongue:

1416 out of 2046 bits of the private exponent have been leaked. And all the other stuff is missing too (prime1, prime2, exponent1, exponent2, coefficient). Not sure if this warrents a revocation, but I'll leave that to @lestaff. The cert in question is (removed, see post history for cert serial and link to crt.sh).


Many thanks for pointing this out! I've hidden the revisions to both posts that contained private information, and we'll handle this further as required.