Need help finding instructions that don't use SUDO

OK. I have tried the same instructions on my cPanel development server, and I ran into the same problem as you. It looks like the instructions are outdated.

Here is what I did to get it to work (the only difference really, is --register-account instead of --update-account):

$ curl | sh

$ source ~/.bashrc

$ --register-account

$ uapi DomainInfo single_domain_data | grep documentroot
    documentroot: /home/monkas/public_html/a

$ --issue --webroot /home/monkas/public_html/a -d --staging

Confirm that the above is successful, then do it for real:

$ --issue --webroot /home/monkas/public_html/a -d --force

Confirm that the above is successful, then we can deploy the certificate to cPanel;

$ export DEPLOY_cPanel_USER=$USER
$ --deploy --deploy-hook cpanel_uapi --domain
1 Like

I’m working on the uapi command. Do I type that exactly as written, or am I supposed to insert my domain info in places?
I suspect I should put ~public_html/web/syihtq because that is where the actual website resides.

I tried it and got the error message
Odd number of elements in hash assignment at bin/ line 149.
warn [uapi] Could not find “single” in module “Domain Info” at /usr/local/cpanel/Cpanel/ line 309

The uapi command is just for discovering your document root (with your own domain). You’ve already identified yours, so you can use ~/public_html/web/syihtq . Mind the positions of the /, they’re important.)

Oh. I didn’t realize that. I know where the files are, so I’ll just go to the next command. Ignore the error message.

I know it’s a moot point now, but it’s really important to be careful to copy the commands exactly as written. You’ve omitted underscores and inserted random spaces. Nothing will work otherwise!

Yes, I do know that. It’s just difficult for me to get it exactly right.
And now I accidentally deleted my Putty settings and will have to track down my password and key again.
I’m sorry this is taking so long. You are being so kind to help me.

1 Like

I may just jump up and down for joy. It said “Certificate successfully deployed”

So these are the commands I issue for EACH of the 14 domains?

1 Like

Awesome! I can see the certificate that you’ve deployed.

Basically, yeah. You will need to find the correct document root for each addon domain, though.

One additional complication is if you are using “www” versions of your domains in addition to the base domain, like so:


then what you should do, is create certificates which are valid for both versions of the domain.

The way you can do this is by adding extra -d arguments to your commands.

For example: --issue --webroot ~/public_html/ -d --force

would become: --issue --webroot ~/public_html/ -d -d --force

The difference is that I’ve added:


Can I do it after the fact? Would I do the whole command again, or just the one that is missing?
And are there any limits? Sometimes I have several subdomains on the same addon domain.

I think you can, by repeating the --issue and --deploy commands. For the --issue command, you would just make sure to include the other domain aliases.

Well, it depends.

In cPanel, subdomains usually have their own dedicated document roots. For those domains, you should just create separate certificates.

But subdomains that are aliases (such as www., usually), point to the same document root. For those, you can put them on the same certificate.

That’s the rule of thumb I usually use with cPanel, but it does really depend on how you’ve set things up.

And now for the next big question. How do I set it up to automatically renew. Do I do that with a cron job? Or is there no way to do that, in which case I have to type in these commands every 90 days?

I’m pretty sure that has setup automatic renewal for you already.

As long as you successfully do --issue and --deploy, will renew and re-deploy your certificates at appropriate times.

You can check if the scheduled task was installed by running:

crontab -l
1 Like

YES!!! It’s there. At least I assume it - there is a command there with in it.
I cannot tell you how much I appreciate your help. There is a special place in heaven for you.
Thank you, thank you, thank you. All of our non-profit programs are in your debt.


Dare I suggest you pay it forward by writing down what your final procedure was and posting it?

One of the biggest problems for an advanced user is thinking like a newbie. Those instructions will help other people who will be in the same boat as you in several months, when you will no longer be a newbie and no longer able to think like one.

1 Like

I will do that, RichardP, once I’ve managed to get it to work on the rest of my domains (which would indicate that I actually understood and can follow the directions because I don’t want to write down incorrect instructions).

However, I am stuck trying to apply this knowledge to the very first domain I’m trying to do on my own. I follow the same instructions, but instead of working like it did on, I got error messages. I’m trying different things to figure it out right now (I needed to sleep in between, as I was so tired I couldn’t think straight). I’ll come back if I can’t figure it out on my own.

Is it the same environment? Still Godaddy, same OS version, same software.?

Yes, everything is the same as described initially.
Last night, _az helped me get the certificate renewed for (which I never actually had working to begin with). I still need to go through and update all the http in the code to https so that the page is fully secure, but works and when I go to the Godaddy control panel, the renewal date is now October 21, 2019.
So now I’m trying to get it to work on The renewal seemed to work, but when I tried to deploy I got this error message:
Certificate verification failed! The system did not find the Certificate Authority Bundle that matches this certificate. Contact “Fake LE Intermediate X1” to obtain the Certificate Authority Bundle.

I’ve tried to investigate what this is, but have been unsuccessful in finding the answer. I tried deleting the certificate on my end and deleting the cpanel record with the expired certificate and starting again from scratch, but it doesn’t work. (Trying to install the certificate just tells me its already installed, and I just get that error message when I try to deploy.)

Can anyone help me with this error message?

Thanks much in advance.
P.S. I’m going to go ahead and try this process on another domain.

Did you happen to use --staging or --test in any of your commands? That “Fake LE Intermediate X1” is the issuing certificate in the Let’s Encrypt staging environment and is only used for testing.

It sounds like the certificate may not be a “production” certificate. When you are creating a certificate for a new site, there are a number of options you can choose to test your procedures and your scripts. These options are there so that you can create a test version of your site so that you can try things out without breaking the live site in the process. Or they let you test your process for renewal without making the LetsEncrypt server ban you for excessive calls.

It sounds like the problem you are running into is that one or more of your instructions may be creating such a certificate. Look at all the lines looking at your options (the bits following either a dash or double-dash.) Look especially for anything with either “–staging” or “–test”, but any option you find that you do not know the purpose of, find out what it does and if it should be being used in that situation.

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:

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

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

  2. I originally used a fourth party (ZeroSSL) website following a youtube video ( 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.

  3. 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.

  4. 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.

  5. 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 instead of CERTBOT. You can install and use this 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 ( 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 program and open up and register an account:
curl | sh
source ~/.bashrc --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 on a Godaddy shared hosting website: --issue --webroot ~/*public_html/web/subdirectorywherewebsitesits* -d *firstwebsiteforcertificate.tld* -d *www.firstwebsiteforcertificate.tld* -d *secondwebsiteforcertificate.tld* -d *www.secondwebsiteforcertificate.tld* --staging 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 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 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, 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 --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. --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.)

1 Like