godaddy shared hosting acme.sh - apache

I am trying setup a free HTTPS on my godaddy shared hosting (its cPanel enabled) following the info on https://github.com/Neilpang/acme.sh from my mac.
However I am stuck...
What I have done so far:
Established an SSH connection to the server
Installed the acme as documented:
git clone https://github.com/Neilpang/acme.sh.git
cd ./acme.sh
./acme.sh --install
3.Closed the connection and reestablished (was required as indicated for getting the paths right or something)
4.Issues the certificate:
acme.sh --issue -d mydomain.com -w www --debug
I found that www is the directory in which my website resides...
After approx 10seconds the command says "Cert success"
Then I am lost...
The acme website says "3. Install the issued cert to Apache/Nginx etc."
with a command like:
--apache--
acme.sh --installcert -d example.com \
--certpath /path/to/certfile/in/apache/cert.pem \
--keypath /path/to/keyfile/in/apache/key.pem \
--fullchainpath /path/to/fullchain/certfile/apache/fullchain.pem \
--reloadcmd "service apache2 restart"
or
-nginx-
acme.sh --installcert -d example.com \
--keypath /path/to/keyfile/in/nginx/key.pem \
--fullchainpath /path/to/fullchain/nginx/cert.pem \
--reloadcmd "service nginx restart"
I guess godaddy is using apache?
What are these /path/to/certfile/in/ directories? What are they for my godaddy installation?

If you are using godaddy shared hosting, you can not restart/reload apache to enable the cert, since you are not root user.
So, you can not use acme.sh --installcert ... command.
Please copy the cert and key, and set the cert/key in you cpanel dashboard.
Thanks.

Related

Why isn't certbot writing the verification file?

I am trying to install a certificate using certbot on Ubuntu Xenial by using the below command:
sudo certbot run -a webroot -i apache -w /var/www/mydomain/public/.well-known/acme-challenge/ -d "example.com"
I get a challenge failed error with the following notes:
Domain: mydomain.com
Type: unauthorized
Detail: Invalid response from
http://example.com/.well-known/acme-challenge/lvJ9RbuDyoPn4NXnxPpjOYpsGHZb6ZYdDoBWW-6JC1k
I created the /.well-known/acme-challenge myself thinking this might help, but it didn't. I tried putting a file into the acme-challenge directory and browsed to it through Chrome and this worked without an issue. Therefore, I know the Apache host is setup correctly.
I'm now at a loss of what to try.

Problem in getting SSL Certificate for my domain at digitalocean droplet through Let's Encrypt

I was trying to get SSL certificate for my domain on PhpMyAdmin Droplet by following the steps mentioned at "https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-18-04". My server is Ok. I have DNS A entry for my domain.com and CNAME entry for my www.domain.com
As I went to execute "sudo certbot --apache -d your_domain -d www.your_domain"
It asked me to enter email address and after that it gave me the following error.
"An unexpected error occurred:
The client lacks sufficient authorization :: Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for details.
"
I tried with root and non root admin user with sudo but still the same. Any help is appreciated
Best
I got it resolved. So first run
sudo apt update
sudo apt install --only-upgrade certbot
and then
sudo certbot --apache -d your_domain -d www.your_domain
worked for me

Letsencrypt + Docker + Nginx

I am referring this link https://miki725.github.io/docker/crypto/2017/01/29/docker+nginx+letsencrypt.html
to enable SSL on my app which is running along with docker. So the problem here is when I run the below command
docker run -it --rm \
-v certs:/etc/letsencrypt \
-v certs-data:/data/letsencrypt \
deliverous/certbot \
certonly \
--webroot --webroot-path=/data/letsencrypt \
-d api.mydomain.com
It throws an error:
Failed authorization procedure. api.mydomain.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://api.mydomain.com/.well-known/acme-challenge/OCy4HSmhDwb2dtBEjZ9vP3HgjVXDPeghSAdqMFOFqMw:
So can any one please help me and let me know if I am missing something or doing something wrong.
What seems to be missing from that article and possibly from your setup is that the hostname api.mydomain.com needs to have a public DNS record pointing to the IP address of the machine on which the Nginx container is running.
The Let's Encrypt process is trying to access the file api.mydomain.com/.well-known/acme-challenge/OCy4HSmhDwb2dtBEjZ9vP3HgjVXDPeghSAdqMFOFqMw. This file is put there by certbot. If the address api.mydomain.com does not resolve to the address of the machine from which you are running certbot then the process will fail.
You will also need to have ports 80 and 443 open for it to work.
Based on the available info that is my best suggestion on where you can start looking to resolve the issue.

Let's Encrypt configuration on Apache

When I run
./letsencrypt-auto
I can choose my domains, but in the next step it fails on
IMPORTANT NOTES:
- The following 'urn:acme:error:connection' errors were reported by
the server:
Domains: xx.co.uk
Error: The server could not connect to the client for DV
Does apache needs to be listening on port 443 already or what else could be a problem?
Apache 2.2, Ubuntu 14 LTS Trusty
I just started using Let's Encrypt. My server runs Apache 2.2 on Ubuntu 12.04. I found it much easier to use Let's Encrypt certonly --webroot mode. Here's an example:
./letsencrypt-auto certonly --webroot \
--renew-by-default --agree-tos \
--email postmaster#analysisandsolutions.com \
-w /var/www/www.analysisandsolutions.com/public_html \
-d www.analysisandsolutions.com -d analysisandsolutions.com
Then I edited the relevant virtual host file in sites-available to contain:
SSLCertificateFile /etc/letsencrypt/live/www.analysisandsolutions.com/cert.pem
SSLCertificateChainFile /etc/letsencrypt/live/www.analysisandsolutions.com/chain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.analysisandsolutions.com/privkey.pem
Finally call service apache2 reload
I also use the resulting certificate for Postfix SMTP and Dovecot IMAP connections.
I made a shell script to simplify the process. More details about all of this can be found on my blog.
Here is an answer.
Yes Apache needs to be listening on 443. Easiest way is to make you domain working with self signed SSL certificate.
Then run
./letsencrypt-auto --apache
And Let's Encrypt does all for you. Amazing!

FreeIPA request certificate with cname

I while ago I was wondering how I could create an ssl-certificate for a cname. This came up as we always use generic a-records for our virtual machines. Services running on those virtual machines should be accessed by users by their service name over SSL. We use FreeIPA as our Certificate Authority.
Sometimes you search for an answer for ages, and find the answer on multiple websites which are not very clear. I will explain my answer by means of an example to show the differences in requesting a certificate from FreeIPA with a cname and without a cname.
We make an imaginary virtual machine with an a-record being abc955-xy.example.com. On this machine we will run postgres. So, out of convenience, the cname will be postgresql.example.com. First we create a certificate for abc955-xy.example.com, which is only valid for the fqdn. Second, we create a certificate for the cname, which is also valid for the fqdn.
Certificate without a cname
# Generate a private key
openssl genrsa -out abc955-xy.example.com.key 4096
# Add the host to FreeIPA
ipa host-add abc955-xy.example.com --force
# Create a host principal for the service HTTP
ipa service-add HTTP/abc955-xy.example.com
# Add the host principal to the host
ipa service-add-host HTTP/abc955-xy.example.com --host abc955-xy.example.com
# Request a certificate for the host, using the principal and private key
ipa-getcert request -r -f abc955-xy.example.com.crt -k abc955-xy.example.com.key \
-K HTTP/abc955-xy.example.com -D abc955-xy.example.com
Cerfificate including a cname
# Generate a private key
openssl genrsa -out postgresql.example.com.key 4096
# Add the host to FreeIPA, using the cname
ipa host-add postgresql.example.com --force
# Create a host principal for the service HTTP
ipa service-add HTTP/abc955-xy.example.com
# Create a principal for the service HTTP with the cname
ipa service-add HTTP/postgresql.example.com --force
# Add the cname principal to the host
ipa service-add-host HTTP/postgresql.example.com --host abc955-xy.example.com
# Request a certificate for the host, using the principal and private key and cname
ipa-getcert request -r -f postgresql.example.com.crt -k postgresql.example.com.key\
-K HTTP/postgresql.example.com -D postgresql.example.com -D abc955-xy.example.com
Other than some naming differences, the main difference between both options is that you add the HTTP-principal with the cname to the host instead of the HTTP-principal with the fqdn.
Note: since browsers such as Chrome and Chromium only accept certificates with a Subject Alternative Name (SAN) as of version 65, you need to add a Subject Alternative Name to certificates without a cname too. This is where the option -D comes from in the ipa-getcert request. For certificates without a cname, you have to supply the fqdn.
# Set variables
DOMAIN=domain.name
CNAME=cname
DEST_MACHINE=dest-machine
# Add CNAME DNS-record
# $CNAME => $DEST_MACHINE
ipa dnsrecord-add $DOMAIN $CNAME --cname-hostname=$DEST_MACHINE
# Generate a private key
## to /etc/pki/tls/private
## or another dir (*selinux fcontext* of that dir should be *cert_t*)
sudo openssl genrsa -out /etc/pki/tls/private/$CNAME\_$DEST_MACHINE.key 4096
# Create HTTP service for $DEST_MACHINE\.$DOMAIN
ipa service-add HTTP/$DEST_MACHINE\.$DOMAIN
# Add alias HTTP/$CNAME\.$DOMAIN for HTTP/$DEST_MACHINE\.$DOMAIN
ipa service-add-principal HTTP/$DEST_MACHINE\.$DOMAIN HTTP/$CNAME\.$DOMAIN
# Request a certificate for HTTP/$DEST_MACHINE\.$DOMAIN
# for a DNSNAMEs:
## $DEST_MACHINE\.$DOMAIN
## $CNAME\.$DOMAIN
sudo ipa-getcert request -r \
-f /etc/pki/tls/private/$CNAME\_$DEST_MACHINE.crt \
-k /etc/pki/tls/private/$CNAME\_$DEST_MACHINE.key \
-K HTTP/$DEST_MACHINE\.$DOMAIN \
-D $DEST_MACHINE\.$DOMAIN \
-D $CNAME\.$DOMAIN
# Show info about certificate requests
sudo ipa-getcert list
# List content of certificates dir
ls /etc/pki/tls/private/
# Now just use that certificates with your web-services