Linux servers.

How to Use Let's Encrypt TLS Certificates on GoDaddy Shared Hosting

The Goal

I wanted to update a set of web sites that are hosted on GoDaddy. The sites had been there for a while, hosted on "Economy Linux" platforms that had been the standard when the sites were created. In the past year or two GoDaddy had moved forward to their newer "Economy Linux with cPanel" platform.

The newer platform was based on a significantly newer distribution, meaning security improvements and possibly performance improvements. What's more, the price had dropped, no doubt due to the rise of Google Cloud Platform. If I was deploying those sites today, I would go with the Google Cloud Platform.

This happened in September 2017, when Google was warning that Chrome would start displaying "Insecure" on plain old HTTP pages within a few weeks, and a lack of HTTPS would start to hurt you in search result rankings some time in the coming months.

The business owner of one of the sites had purchased a TLS certificate from GoDaddy for about US$ 60/year. On the other sites I went with free Let's Encrypt TLS certificates.

GoDaddy wants to sell certificates to make up for reduced hosting income, so while they don't block the use of Let's Encrypt certificates, they certainly don't help you to do it. But it's not at all hard to do.

Step 1: Upgrade

The old platform was really old. It had a file /etc/*-release which revealed that it was based on CentOS 5.5!

Its version of OpenSSH was so old that it still supported nothing but the DSA (or ssh-dss) public-key algorithm for host keys. OpenSSH 7.0 and later disabled DSA host keys. That meant that you no longer could connect from reasonably current platforms without adding a stanza to the bottom of your /etc/ssh/ssh_config file:

$ tail /etc/ssh/ssh_config

## GoDaddy only supports the ssh-dss (DSA) public key algorithm
## for host keys.  OpenSSH 7.0 and greater disables it.  For
## details see:
   HostkeyAlgorithms ssh-dss 

The newer GoDaddy platform, current as of September 2017, is CloudLinux OS. It's really stripped down, with neither os-release nor lsb-release in /etc. CloudLinux OS is fully compatible with CentOS/RHEL packages.

It is also really tightened down. Your home directory is the only subdirectory of /home. You can only see your own processes in /proc and with ps and top. The /dev/ directory has very few devices other than the pseudo-ttys. No disk devices appear! It uses CageFS, making it similar to a container.

The OpenSSH service is version 5.3, two major releases behind the current, but it's new enough to interoperate with an OpenSSH 7.5 client.

$ ssh -vv uname -a
[...  output deleted   ...]
[... here are versions ...]
debug1: Local version string SSH-2.0-OpenSSH_7.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
[...        output deleted        ...]
[... here are server capabilities ...]
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ssh-dss
[... and cipher/MAC offers both ways ...]
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,
debug2: MACs ctos: hmac-md5,hmac-sha1,,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5,hmac-sha1,,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,,hmac-sha1-96,hmac-md5-96
[...       output deleted        ...]
[... here's what they agree upon ...]
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: compression: none
[... output deleted ...]

I had the usual excellent live help over the phone. That's good, because GoDaddy's graphical panels are mysterious.

A roundabout sequence of clicks, copy, paste, and more clicks can get an authorized public key uploaded. That is, the public key matching the private key of a user identity.

Surprisingly, you still can't log in directly even though you just uploaded a key that was installed in ~/.ssh/authorized_keys (and, also, authorized_keys2 for some reason). You have to go back to the cPanel web interface and do some clicking that leads to authorizing that new key identity.

You can't see what's going on, but I'm guessing that you have to get the newly configured user identity listed as an AllowUsers entry in the sshd_config file. CageFS hides the details, in /etc/ssh you only see the filese ssh_config and moduli.

Once you can load your private keys into your SSH agent on your client and then make seamless key-based SSH connections, you're ready to move on.

Credit Where Credit Is Due

I created this page so I will have notes on how to do this even if other sites change or disappear.

The deployment steps in the following are based on those on the great site. Some steps on that page came from other contributors. And finally, all this is built on top of work by the authors of the tool. That's a shell script implementing the ACME client protocol. ACME or the Automatic Certificate Management Environment is a protocol for automating interactions with certificate authorities.

There is no need for Python or Go or the official Let's Encrypt client, as is a pure shell script. Nor is there any need for root access. This gives us an ACME tool for the shared hosting environment.

Step 2: Install

Log in to your GoDaddy shared hosting system and run the following to download and then install the tool.

$ cd
$ curl | sh -s
$ source .bashrc

Two lines have been added to ~/.bashrc, referencing a two-line file that sets an environment variable and defines an alias:

$ cat ~/.bashrc
# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc

# User specific aliases and functions
. "/home/myusername/"
$ cat ~/
export LE_WORKING_DIR="/home/myusername/"

Step 3: Get a GoDaddy API Key and Secret String

On your local desktop, start a browser and load

For some unexplained reason you must first generate a test key/secret pair. It's a single button click. Then you can generate a production key and secret.

I used vim within my SSH session to edit ~/ and store both pairs.

$ cat ~/
Test key:
Key:    qsLLqQyqhu6Lx1q85ctZbNYT90daRvR25
Secret: Bdx4ap8gi0kK8jOosHD1zf

Production key:
Key:    AHoQgGr+qi1qModOIKZTktXzGak6C1MV0K
Secret: mkNmVBf/6ZaWkMx0Bi5sX2

Of course those aren't the actual values! They're the result of using dd to send several bytes from /dev/random into the base64 command to provide appropriately sized examples.

Step 4: Issue a Certificate

Set two environment variables and then you're ready to issue a certificate. The --help option explains the pieces and suggests other options. The certificate will be good for the domain itself plus

$ export GD_Key=AHoQgGr+qi1qModOIKZTktXzGak6C1MV0K
$ export GD_Secret=mkNmVBf/6ZaWkMx0Bi5sX2
$ --help
[... 94 lines of output ...]
$ --issue \
	--domain \
	--domain \
	--webroot ~/public_html --dns dns_gd 
$ ls ~/
./      fullchain.cer

There will be a lot of narrative output, including multiple countdowns for DNS updates to take effect. A subdirectory of ~/ named for the domain will appear, and the key and certificate along with the intermediate CA certificate, full chain certificates, certificate signing request, and CSR configuration will be stored there.

Step 5: Upload the Certificate and Private Key to GoDaddy

We can call the cPanel API from our command line. First, edit to uncomment the DEPLOY_CPANEL_USER line and set the variable to your numeric GoDaddycustomer ID.

$ head ~/
# Here is the script to deploy the cert to your cpanel using the cpanel API.
# Uses command line uapi.  --user option is needed only if run as root.
# Returns 0 when success.
# Written by Santeri Kannisto <>
# Public domain, 2017

#export DEPLOY_CPANEL_USER=myusername
export DEPLOY_CPANEL_USER=12345678 

Now you can deploy the certificate and key:

$ --deploy --domain --deploy-hook cpanel_uapi 

You should see a message that the certificate was deployed.

Your site should now be available via HTTPS. Test it!

Step 6: Verify Continuing Renewal

The deployment has set up a nightly cron job, scheduled for a random minute between 0000 and 0100. Mine got 0032:

$ crontab -l
32 0 * * * "/home/myusername/"/ --cron --home "/home/myusername/" > /dev/null 

You can run the cron job manually:

$ --cron --home ~/
===Starting cron===
Renew: ''
Skip, Next renewal time is: Sat Nov 25 16:34:49 UTC 2017
Add '--force' to force to renew.
===End cron=== 

You will see that your certificate is good for 90 days, and it will be renewed when 30 days remain. As the command suggests, you can add --force to make it happen. You will see that it generates and installs the private key and certificate and then deploys them.

Step 7: Set Up Redirection

I want to redirect all requests to the "non-www" hostname, and redirect all HTTP requests to HTTPS. That is, all of these URLs:
should be redirected to:

Add the following block to the end of ~/public_html/.htaccess. Don't repeat "RewriteEngine on" if it's already in the file:

$ tail ~/public_html/.htaccess

# Remove "www." and redirect to https
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Also change "http" to "https" throughout the rest of your .htaccess and sitemap.txt files.

Test everything and make sure that it's working.

Congratulations, you're done! For now...

Step 8: Stay Up To Date

Some time in April 2018, GoDaddy changed their API. All at once, failed and the certificate started to count down to expiration.

Update your code.

$ ~/ --upgrade 

Upgrading to v2.7.9 solved the April 2018 problem.

Let's Encrypt, ACMEv2, and RFC 8555

In June 2021, Let's Encrypt phased out support for ACMEv1, having replaced it with the ACMEv2 API as described in RFC 8555. You need to update your client. Save your old ~/ file and copy it into the new version:

  1. $ mv
  2. Do "Step 2" above.
  3. $ cp
  4. Now repeat Steps 3-6 above.
$ ~/ --version

Further Exploration

You can examine certificate details with the openssl command:

$ openssl x509 -in ~/ -text -noout | less
        Version: 3 (0x2)
        Serial Number:
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
            Not Before: Sep 26 15:35:00 2017 GMT
            Not After : Dec 25 15:35:00 2017 GMT
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
            X509v3 Subject Key Identifier: 
            X509v3 Authority Key Identifier: 

            Authority Information Access: 
                OCSP - URI:
                CA Issuers - URI:

            X509v3 Subject Alternative Name: 
            X509v3 Certificate Policies: 
                  User Notice:
                    Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at

    Signature Algorithm: sha256WithRSAEncryption

You might also try this:

$ openssl s_client -connect -servername