Manual LetsEncrypt for cPanel

At work I recently collaborated with our hosting provider to move our company website to a version of cPanel. Up until this time, there has been no way of running our site on SSL/TLS, and it's been quite frustrating, having discovered LetsEncrypt and its ease of use. Basically, with this certificate signer, I have no reason to actually figure out the handshaking and signing process as was required in old command-line versions of SSL.

Well, our hosting provider's version of cPanel has not really been expanded to allow for LetsEncrypt, even though multiple people on the cPanel forums say there's a plugin available. Seems they don't mind forcing me to pay another fee on top of everything to get an annual signature from the two default signers they had enabled in the system.

This made me wonder, and think, well CertBot, which generates the certificates and private keys and runs the signing requests automatically, always talked about this "cert only" option, and here on their website, I see instructions for a "manual" option as well. I thought this may have been exactly what I was looking for, since my scenario is - I have a website on a host who does not have LetsEncrypt enabled, but does allow me to upload certificates and keys from an offline source.

Here is my process of installing a LetsEncrypt SSL/TLS DV certificate on a cPanel site not equipped to generate one automatically.

Create a new certificate with any subdomains we'd need using certbot certonly -d c-pwr.com,www.c-pwr.com --manual

Certbot warns you that the computer's IP you're generating the certificate on will be shared with them, even though it's not the server on which the cert will be installed on in the end. Type Y.

Without any "challenges" option in the original command, certbot assumes you're using the acme challenge which involves uploading a text file to your site. Using cPanel's file manager I simply do this.

Once the first file in acme-challenges is created, certbot asks us to create another file in the same place with a different string as its contents.

Once both files are created and saved to this location, we probably should verify that the URLs certbot is pointing to are actually visible from the public web.

Knowing that I can access the challenge files from my browser, I assume certbot will also be able to access them, presumably from a curl command or something, so I let it continue.

If we get the standard certbot success message, we now see that it's created our certificate, chain and private key files in certbot's standard location (I'm using the PPA repository through aptitude, so certbot automatically installs the latest versions of my certificates to /etc/letsencrypt/live/c-pwr.com/, which are actually symbolic links to /etc/letsencrypt/archive/c-pwr.com/, as every time we renew, it will archive the old files and create new ones.

I now can copy the contents of both /etc/letsencrypt/live/c-pwr.com/cert.pem and /etc/letsencrypt/live/c-pwr.com/privkey.pem up to cPanel in their SSL interface.

After this, I head over to the Manage SSL Sites tool and install this certificate as-is. It automatically detects the domains I specified in the original certbot command and applies the certificate to them.

Back on the main site, I now can see that https://www.c-pwr.com now works, and gives me the certificate information including how long it will be valid.

At this point, I have no idea how the renew will work. Since LetsEncrypt issues certificate signatures for only 3 months, this will become an issue sometime in August. I HOPE the acme-challenges will remain the same, but if they don't, it should be a simple task to recreate the files as above, then copy the files in manually, assuming certificates and private keys can be edited once created in cPanel.
Renewing is super simple, but with this method must be run differently from certbot renew. I simply ran certbot certonly -d c-pwr.com,www.c-pwr.com --manual again. It asked me to create new acme challenges on the webserver, but since the cert already existed, it detected this as a renew, and did not prompt me to upload certificates a second time!! Just created two text docs, hit enter in my local server command line and it did everything from there.

Additionally, I should probably set up my .htaccess file to redirect any http requests to the https version. This is usually done automatically by certbot during an automatic installation, and is embedded in the /etc/apache2/sites-available/000-default.conf file, but since I don't have access to this, .htaccess will have to do.

A fun adventure in PGP

So I got curious about PGP keys and signing and encrypting using them. I managed to figure out how to use the semi-popular gpg4win (the standard windows port of GnuPG) with its built in Kleopatra GUI, Outlook add-ins and all the other fun stuff.

Using gpg from Kleopatra is much more convenient and automated than using gpg from, say, the command line, like many purists would probably recommend, just like the Git purists recommend only committing from the command line (even though the Git gui is way more convenient for diff and history, and so I continue to use it almost exclusively if possible).

Well, what I did not realize up until today was that running gpg from the command line was acting much MUCH differently than when I ran it from Kleopatra. But let's go back in history to describe what I did, what I discovered, and how I rectified the problems I found this morning.

- Getting my new work machine, I immediately installed Windows distribution of git core, which includes my favorite git-gui. This particular version of git (2.13.0.windows.1) completely overhauls the virtual machine folder structure so that rather than running git bash shell from ../Git/bin (a scaled down version of MinGW), it instead runs from ../Git/mingw64/bin/ and ../Git/usr/bin. But that's not the important thing to understand. Rather, what I really didn't understand is that git's mingw comes pre-packaged with gpg. But we're ignoring that so you can re-live my tale of headache.

- Move forward 2 months to when I want to explore gpg for the purposes of signing and encrypting documents, emails, other keys, etc. I installed gpg4win-3.0.0. Kleopatra is a great little gui! I import a few keys to check signatures on things like ubuntu iso files, the actual gpg4win-3.0.0 signature, one I found of a friend (which he confessed he doesn't use anymore). Over time, I accrue over ten keys in my list.

- A few weeks pass. I start reading more, and discover that you can sign git commits!!

Okay, so how do I do this? Well, what if I were to create a new master key and, like I saw a few people doing, label it as "CODE SIGNING KEY?" Sounds pretty reasonable. That I can do without a tutorial in Kleopatra!

Next I head over to https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work. Perfect. I already have the key, but let me do those steps anyway.

From git bash, gpg --list-keys: No default key. Creating pubring.gpg and secring.gpg. Umm..that's odd. Shouldn't the one I just created in Kleopatra be there? Oh well. Let me try this gpg --import EDDD62B2.gpg, since I was careful a month ago to back up public, secret and revocation files. Tried the command again, okay, now it's there.

Changed a file, and from the bash shell, tried git commit -S -m "Test GPG signature": Enter your passphrase. Okay. Did it. Commited! YAY!

Okay, so this will be inconvenient to have to remember the "-S" bit every time I want to do something, plus, hey, if I want to use git-gui, there's no checkbox to sign a commit. Only to add a signature to the commit message (which I verified - "Sign your message" does not gpg sign the commit, even when one is available).

So how do I configure git to force-sign commits? Uhh http://lmgtfy.com/?q=git+force+gpg+signature

Oh this one looks good. Tried the instructions in https://stackoverflow.com/a/20628522/1265581 and sure enough, now git commit -m "Next test gpg signature (should be automatic)" totally asks for my passphrase, and git log --show-signature verifies the signature! Hooray!

So next step, does this work in git-gui? Tried it, uh...no. Big error (which I don't remember). Well, dang. So apparently, I can do all my diffs, my staging, and writing up the commit mess....no wait. Apparently git bash doesn't like a typical right-click/paste. So I have to open git-gui to stage and diff, and git bash AT THE SAME TIME to write the commit message and actually perform the commit. Well. That's not fun. But I'll do it.

- One more week later. I am now working on a hardware controller utility on my laptop. Time to get my secret keys transferred over so I can work from there. Obviously I want to see about getting the new git-gui installed too. Now I have git 1.9.5-preview20150319 installed as a 32-bit program, git 2.15.0.windows.1 installed as a 64-bit program (both of which I STILL did not yet realize had their own versions of gpg.exe). Also I had gpg4win-3.0.0 installed from before, to check whether or not emailing an encrypted message would work properly via the Outlook addin (which it did).

Set it up exactly like I had it on my desktop and....wait, now signing DOESN'T work? What's going on!? So now I'm subjecting myself to workarounds of transferring code via flash drive to a workstation that can properly sign the commits.

Plus I have not yet caught on that there's a reason why running gpg --list-keys is returning only my own keys, while Kleopatra shows over 20 in my list. And why I went through a huge bout of 'why in the world is it saying pubring is down in AppData when on my desktop they're all in ~/.gnupg, which I thought -I- created, but probably didn't?

- On to today. I want to sign and symmetric-encrypt a text document in plaintext (armor) format. While I can do all of the Right Click > Sign and Encrypt from my Windows context menus, it never gives me the armor option. But the binary gpg file it generates will totally decrypt fine in Kleopatra, so it should work in the command line, right?

So I try it in the command line via gpg --encrypt text.txt --armor --symmetric -o test.asc. Okay, this works fine. But then running decrypt from Kleopatra and I get "No valid OpenPGP data found." Uhh...why?

More Google, and I discover http://unix.ittoolbox.com/groups/technical-functional/shellscript-l/unable-to-decrypt-the-file-using-gpg-5012722 one, which offers (in my case) the workaround to add --force-mdc which is some security thing that my version isn't using by default? Well how do I make it by default? Add something to ~/.gnupg/gpg.conf? Well let me see..

It is at this point that something fires in my brain and I think, "wait... does my LAPTOP show all of my gpg keys? Sure enough, they do. All the ones I imported from Kleopatra are visible. But Git does not want to sign any commits with anything I have anyway. That means Kleopatra somehow is reading from its standard pubring (in ~/AppData/Roaming/GnuPG), where as gpg from the command line is reading the pubring from... ~/.gnupg/."

How do I force the command-line version to read from the pubring.kbx file instead of pubring.gpg? Research research research. Environment variables to switch databases...just creates an empty pubring.gpg in the location where pubring.kbx is located. No way I can make it read the kbx file that's already there??

At this point, I read somewhere that 'gpg 2 and up uses the kbx file format, where as versions lower than that use gpg. You will need to do this and this to merge them.' Well what's MY version? 1.4.21. But if I run "C:/Program Files (x86)/GnuPG/bin/gpg.exe" --version, I see 2.2.1! Ohh..so SOMETHING is forcing the Windows command line to use a different, OLDER copy of gpg.exe somewhere, probably out of my path.

A bit of research later and I discover that yes, indeed, Git has its own copy buried down inside of the program directories! Well, can I force git to use the gpg4win version? There's this command I can run to configure git to use it...but it doesn't seem to want to work.

What if I rename ../Git/usr/bin/gpg.exe to gpg.xex? Yep, THAT works then. Now both git bash shell and windows command line use C:/Program Files (x86)/GnuPG/gpg.exe, as does Kleopatra!

But will git sign commits properly? Let's give it a shot. Edit text file, git commit -S -m "Test commit." Asks for passkey. Success! Wonderful! Ooh though now I wonder... what would happen if I tried a commit in git-gui?

Open git-gui, change a file, save, rescan, stage, type message, I know that git is configured to force signatures, so let's just commit...aaaaand popup requesting passkey! EXCELLENT!!

Back out to windows command line and gpg --version. gpg 2.2.1. Excellent AGAIN!

Switch to my laptop. Rename gpg.exe to gpg.xex. And now it reads gpg 2.2.1 in both windows command line and bash shell on both computers! I'll write a blog post before I test whether or not it can now correctly sign commits.