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.
8 Likes
UPDATE: Fixed! I didn't realise you meant "-----BEGIN PRIVATE KEY-----" by "header". 
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.
5 Likes
I would probably do this:
- Define constants at the top of the script, as @bruncsak suggested
- If there is a
certsage.config.phpfile 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.
5 Likes
Usually, there are some "boundries" above and below the certificate and private key, looking like:
-----BEGIN CERTIFICATE-----
and
-----END CERTIFICATE-----
for the certificate and the private key usually has:
-----BEGIN RSA PRIVATE KEY-----
and
-----END RSA PRIVATE KEY-----
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 ?
7 Likes
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.
7 Likes
It's way easier to just typ it all over instead of using garbage OCR programs.. 
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).
7 Likes
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.
7 Likes
That should be enough to reconstruct d, see e.g this for the theory. The other data in the PKCS structure is fully redundant and actually not needed for most things, but can be reconstructed from d if needed.
6 Likes
Still sounds pretty hard to do.. I'm not going to attempt it if there aren't any tools laying around to do it for me
7 Likes
Welcome to the Let's Encrypt Community, Hazel 
Thank you! 
I did some additional checking on your certificate usage. Looking great! 
Your certificate installation looks great per https://decoder.link/sslchecker/gigglemugcomedy.com/443 .
Your redirects look fantastic per Redirect Checker | Check your Statuscode 301 vs 302 :
http://gigglemugcomedy.com
301 Moved Permanently
https://gigglemugcomedy.com/
200 OK
http://www.gigglemugcomedy.com
301 Moved Permanently
https://www.gigglemugcomedy.com/
301 Moved Permanently
https://gigglemugcomedy.com/
200 OK
Qualys SSL Labs SSL Server Test gives gigglemugcomedy.com an A rating:
https://www.ssllabs.com/ssltest/analyze.html?d=gigglemugcomedy.com
Also, thanks for the feedback about the "header" and "footer" confusion. I will add clarification in the instructions for the next release.
If your current certificate does need to be revoked, no worries. Just acquire and install another one exactly as you did the first time. Consider it practice and an early renewal since that's exactly the same thing you'll do to renew your certificate in 60 days or so.
Certificate history of gigglemugcomedy.com :
5 Likes
I fully concur. I was strongly leaning towards going back to only the first bullet, but your follow-up comment convinced me of a value I overlooked in having an external configuration file. Thanks for that!
4 Likes
CertSage does not presently offer revocation functionality (mostly to prevent random abuse), but could if circumstances called for it. I'll consider adding it in the upcoming release.
5 Likes
Special thanks to @Osiris, @Nummer378, and @JamesLE for diligently looking out for @hzlvns!
7 Likes
For the layman, an RSA private key contains the following values in this order:
| Name | Variable/Formula | Public/Private |
|---|---|---|
| Modulus | n = pq | Public |
| Public Exponent | e | Public |
| Private Exponent | d | Private |
| Prime 1 | p | Private |
| Prime 2 | q | Private |
| Exponent 1 | d mod (p - 1) | Private |
| Exponent 2 | d mod (q - 1) | Private |
| Coefficient | q-1 mod p | Private |
The number of bits of the modulus (n) is the key strength (usually 2048, 3072, or 4096 bits).
The value of the public exponent (e) is almost always 65537.
Some light reading that covers the basics:
6 Likes
Glad it helps. I use that pattern a lot.
5 Likes
Gah. I'm having some trouble with a new domain and cert that I installed:
kathleenshields.com
Using the SSL checker tool you posted above, I get a couple of errors and it doesn't look like it's using the Let's Encrypt cert, but something self-signed. I didn't get any errors when I installed BUT I installed the private key first before the cert. Could that be the issue? TIA
5 Likes
Retrace your cert installation steps.
Remove it and reinstall it (if you have to).
And also ensure whatever control panel has the correct names "kathleenshields.com, www.kathleenshields.com" on that site.
4 Likes
Well crud. I deleted and reinstalled. I even deleted the default self-signed certs that must have been created when the site was set up.
No luck. It shows the Let's Encrypt cert as installed. Any ideas?
5 Likes
cPanel pairs the private key and certificate. Just go into the private key section of cPanel and delete the private keys associated with any unneeded certificates. This will automatically delete the associated certificates. You can then remove all of the unneeded certificates that don't have private keys paired with them. Note that the instructions I provided above have you install the certificate and its private key together on one screen to prevent confusion.
If you delete ALL of the private keys associated with any domain name, cPanel will usually generate and install a self-signed (snakeoil) certificate for that domain name. This is necessary because the underlying Apache VirtualHost for port 443 (SSL) needs some certificate installed for Apache to run correctly. Keep in mind that the Apache webserver must be reloaded/restarted for any certificate changes to register. You should be able to install a certificate and its private key as I've directed above, which should reload Apache after the installation. You can then purge any unneeded private keys and certificates (including self-signed certificates).
5 Likes
