Well, I haven’t heard from anyone for help on the Certificate verification failed error.
I was able, however, to reproduce the success on another of my domains. So I feel reasonably sure that these instructions will work and can be reproduced. I will start from the beginning and explain everything so that even people with not-much Linux administration experience can understand (I hope).
First - the situation. HPL 501c3 Institute is a non-profit organization that helps other non-profits spread health, prosperity, and leadership to everyone, everywhere. We have about 30 programs under our umbrella, and we help them with things like event management, flyers, email campaigns, volunteer management, tax forms, and website management.
Second - the problem: How can a poor non-profit get rid of the “insecure website” or “connection is not secure” message that displays on browsers? Note: there is nothing insecure about any of these websites; there are no forms, no ecommerce, nothing that should require a secure socket layer (SSL). However, those [%^&*^&] browsers have chosen to deploy a [bogus] message on all websites, whether they need security or not. And it scares off the type of non-technical people who come to read the information on our sites, so we have to eliminate that message. And we can’t afford the huge price that our hosting company is trying to charge each year for EACH domain. We don’t charge for our services, and the non-profits wouldn’t have money to pay if they did. We all work on volunteer labor and don’t have fancy schmancy fundraising staff to bring in bucks.
While investigating this problem (I started over a year ago) I discovered several things:
- SSL is not just an encryption method for ecommerce (as I originally thought), but also a method to verify that the domain is where it says it is, and the domain is reachable where it says it is and not somewhere else. As frustrating as it is, on the whole this transparency is a good thing for everyone on the internet, not a bad thing. Once SSL has been installed, verified, and deployed, you can use https:// instead of http:// to get to the site.
- Implementing SSL (i.e. getting rid of the stupid message) has several steps:
First you have to introduce the domain(s) to a third party (like Letsencrypt) who generates a two part key (which is just a file filled with numbers and letters).
Second, part of the key stays with the third party and part of the key gets installed in a specially named directory on your website (.well-known/acme-challenge).
Third, after installing the key in the folder called .well-known/acme-challenge, the third party has to be able to reach out and verify that the key is there, and that it matches the second part of the two part key it has stored. This is the certifying of the key, or certificate.
Fourth, the hosting platform needs to know that the key has been installed. This appears to be called deploying the certificate.
Fifth, ALL of the links on the site must refer to https://domain.org/link in order for the bogus security message to go away.
Sixth, certificates only last a short amount of time, and the site must be re-verified on a regular basis. In the case of Letsencrypt, they only last 90 days.
(yes, I can hear all you techies saying “well, DUH.” But believe me, most people have no idea of any of this.)
-
None of this is a problem if you have a dedicated server and are technically adept. Lots of directions are available about how to get SSL installed, verified, and deployed. But if you are not, everyone assumes that you will just pay your hoster for the certificates. Or that you will use a hoster who provides the certificates for free. I won’t go into the lengthy story about why I can’t move my sites, but suffice to say I tried and failed, so that’s not an option for me. And paying the outrageous fees that Godaddy charges (especially for something that most hosters provide for free) is something I can’t afford to do. While I did pay GoDaddy for my main site, after I learned that the SSL would not work with any of the addon domains, I started the quest to figure out how to do it myself.
-
I originally used a fourth party (ZeroSSL) website following a youtube video (https://www.youtube.com/watch?v=GPcznB74GPs) to install a couple of the addon domains. After using the application on the website to verify that I properly created the folders and put the key file in them, I went into Godaddy CPanel and pasted the first half of the key in the designated area and the second half of the key in the designated area. Then I went into my html code and changed all the http to https and voila! No more message about insecure connections. However, I only got it working on two of my domains. When I tried on the third and fourth one, it failed, and I gave up trying to get the rest of my sites secured.
-
After the three months, however (which was up on July 19th) I decided that I was going to not only figure out how to renew (which I didn’t know how to do, and which the youtube video wasn’t really clear on), but BUT ALSO figure out how to get it to auto-renew so that I didn’t have to go through this every three months AND figure out how to get it deployed on all of my sites instead of just the first 2.
-
My initial investigation led me to Certbot, but after downloading it, I couldn’t find instructions to install it on a shared hosting. It does not appear to be easy to install and use without superuser rights, which is something that is only available to people with dedicated servers (virtual or otherwise). There was a FAQ that said it didn’t need supervisor rights, but every instruction started with the command SUDO (which is a way of sending a command with superuser rights). That led me to post this initial question here in the community.
-
You can read the travails of the problems I encountered and the help that _AZ gave me in the previous posts of this thread.
But now, after this very long introduction, here is the final solution that worked for me for all of my new sites (thought obviously I’m still having trouble with those I had tried to do before but failed.)
First - use acme.sh instead of CERTBOT. You can install and use this acme.sh without the benefit of SUDO (superuser rights), but you must have SSH (Secure Shell) access to your shared hosting site. You can get that by going to the Dashboard of Godaddy (that’s the webpage you go to before you get into the Cpanel. Sometimes they call that the control panel, but don’t confuse it with Cpanel with is something different.) Under the settings panel on the dashboard, you will see an SSH access option. Click on Manage and turn the SSH access on.
Now SSH is the ability to use a command-line interface. You also use SSH to get into your site at a higher level than public_html using FTP, but FTP (file transfer protocol) only lets you move files, not issue commands. To issue commands, you need a terminal server program. I chose to use PuTTY because I had used it before, but you can use any terminal server program. To install PuTTY you can go to the PuTTY website (https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html) and download it. If you have Windows, the msi file is the installer that will go through installing the program.
Of course if you could just use it, that would be grand. But it would also mean that anyone with a terminal server could do all sorts of nasty things to your site, so it is best to use another private/public key system to ensure that only you can access your website with Putty. To do that, you go to cpanel, under the security panel, choose SSH access. While it uses the same name as the choice from the dashboard/control panel, the SSH access under CPanel is different. It will let you generate and manage the security keys. Click on Manage SSH Keys
Click on Generate A New Key. It will generate a public portion and a private portion of the key. (are you sensing a pattern here?) Anyway - give it a name that you recognize instead of the default name id_rsa. Make up a key password that you will remember. You’ll see a bunch of letters and numbers appear with the statement Key Generation Complete
Download the private portion of the key to someplace on your hard drive that you will remember. The public portion has already been placed in a specially named folder on the website.
In order to use Putty you need to enter the configuration information and then SAVE the configuration so you don’t have to enter it each time you get into PuTTY, but can just LOAD the saved configuration. The info you need is:
host name (the IP address for your website, which you can find by looking on Godaddy dashboard, it is in the upper left corner) under Session
Private key file for authentication under SSH – Auth - this is where you Browse to the path where you stored the private key file you generated.
Auto-login Username under Connection – Data - this is where you put your cpanel username.
Once you’ve loaded these configuration options, when you click on Putty in your application list or as an icon in your desktop, you will get a command line interface box (like what you get when you choose RUN CMD), only this is a terminal server that is connected to your website. It will ask you to enter the Passphrase for key “imported-openssh-key”: and you enter the Password you made up when you generated the key. You will then get a prompt where you can type in commands.
One of my first hurtles was that Putty doesn’t use Ctrl-C to copy and Ctrl-V to paste like most programs do. I got tired of manually typing in every character, so I finally googled it and found out that to paste you click on the right mouse button when you are in a position to type, and to copy you highlight using the left mouse button. I got into the habit of keeping a notepad open so I could copy a command, change a few parameters, and then paste it back into putty to try again. (I often have to try many times before I figure out the right combination.)
Then, once you have PuTTY installed and worked, you have to install the acme.sh program and open up and register an account:
curl https://get.acme.sh | sh
source ~/.bashrc
acme.sh --register-account
So finally, after all that - the final commands. What you’ve all been waiting for - what you need to do in order to install, certify, and deploy SSL using acme.sh on a Godaddy shared hosting website:
acme.sh --issue --webroot ~/*public_html/web/subdirectorywherewebsitesits* -d *firstwebsiteforcertificate.tld* -d *www.firstwebsiteforcertificate.tld* -d *secondwebsiteforcertificate.tld* -d *www.secondwebsiteforcertificate.tld* --staging
acme.sh is the command. --issue is what you are asking it to do. --webroot is the location of the website and -d stands for domain, as in which domain do you want. It appears to be short for
–domain (which I finally found in the https://github.com/Neilpang/acme.sh/wiki/Options-and-Params. I wish I had known about the options and parameters document before I started working with _AZ. It would have been ever so much easier to understand what we were doing, but I did find it after the fact that that explained a lot.)
This first command actually just tests the stage to see if it will work. That way you get all the error messages before you actually try to deploy to see if your syntax is correct and the websites are reachable by acme.sh. Most websites are under public_html directly, but I used addon domains, so they were all under a subdirectory called web under public_html. (Part of my problem with the instructions, which often only gave the public_html. You might also need something else instead of the tilde (~), but that worked for me. That’s going to be different based upon however your host is set up. In my case it was /home/taiji2014 (which is my username). I tried it both ways, and they both seemed to work for me.
If you only have one domain, there will only be one -d domain.tld tld stands for top level domain, and it usually is .com or (if you are a non-profit like me) .org. If you use an alias like www (which is just a different way of pointing to the same domain.tld) then you need to include that as well. At any rate, once you’ve tried it, acme.sh will give a bunch of commands and if everything worked out correctly, it will end with And the full chain of certs is there with a subdirectory on your website. If it worked, do the same command again, using --FORCE instead of --STAGING
acme.sh --issue --webroot ~/*public_html/web/subdirectorywherewebsitesits* -d *firstwebsiteforcertificate.tld* -d *www.firstwebsiteforcertificate.tld* -d *secondwebsiteforcertificate.tld* -d *www.secondwebsiteforcertificate.tld* --force
You should get the exact same messages as you got for the staging, only this time it actually completed the key installation. Next, you enter the command:
export DEPLOY_cPanel_USER=$USER
I don’t exactly know what this does or why you enter it, but it appears to be part of the preparation process to tell cpanel that a new SSL key has been installed, which is what you do with the next command.
acme.sh --deploy --deploy-hook cpanel_uapi -d *firstwebsiteforcertificate.tld* -d *www.firstwebsiteforcertificate.tld* -d *secondwebsiteforcertificate.tld* -d *www.secondwebsiteforcertificate.tld*
If you go into cpanel, under the Security Panel, click into SSL/TLS. Then go into Install and Manage SSL for your site (HTTPS)
It should also automatically set up the cron job to check for renewals and automatically renew, but I have yet to test that part.
Anyway - sorry to write a book. But I personally know for a fact that there is no one place anywhere on the internet where it takes you through the whole process, beginning to end, to install, certify, and deploy SSL certificates for multiple websites on Godaddy (or, I assume, any other hoster who doesn’t already provide this very needed service for free.)