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.
Related
I need to get an certificate for my domain hosted on AWS Route 53 from LetsEncrypt. I do not have any port 80 or 443 exposed since the server is used for VPN and does not have a public access.
So the only way to do this is via DNS validation of route 53.
So far I have installed certbot and dns-route53 plugin
sudo snap install --beta --classic certbot
sudo snap set certbot trust-plugin-with-root=ok
sudo snap install --beta certbot-dns-route53
sudo snap connect certbot:plugin certbot-dns-route53
I have created a special user in my AWS account who has access to Route53 and I have added the access key id and secret access key in the ~/.aws/config and also ~/.aws/credentials which looks something like this
[default]
aws_access_key_id=foo
aws_secret_access_key=bar
Basically followed every step given here: https://certbot-dns-route53.readthedocs.io/en/stable/
Now when I run the following command:
sudo certbot certonly -d mydomain.com --dns-route53
It gives the following output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator dns-route53, Installer None
Requesting a certificate for mydomain.com
Performing the following challenges:
dns-01 challenge for mydomain.com
Cleaning up challenges
Unable to locate credentials
To use certbot-dns-route53, configure credentials as described at https://boto3.readthedocs.io/en/latest/guide/configuration.html#best-practices-for-configuring-credentials and add the necessary permissions for Route53 access.
I went to the documentation given in the error message: https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html#best-practices-for-configuring-credentials
but I do not think there is anything wrong I am doing
I even went to the root level by doing sudo su and exported the AWS keys as env vars there and even exported the AWS keys in the home as well but it still throws me the same error.
so I also ran into this same issue, and it's likely because of you running certbot with sudo, when do you do that, whatever user you've used as ~/, is ignored, as instead, it's looking in /root/.
I fixed it by (centos) is my user where I have the .aws/ directory with config and credential files.
sudo -s
ln -s /home/centos/.aws/ ~/.aws
ls -lsa ~/.aws
... /root/.aws -> /home/centos/.aws/
I have a script that runs every day on an Ubuntu 14.04 server. The script is a simple wget command that downloads a file from a remote server and saves it to the local file system:
wget https://example.com/resources/scripts/myfile.php -O myfile.php
It has worked fine for months until this morning when suddenly when I run it I get:
--2020-05-30 11:57:16-- https://example.com/resources/scripts/myfile.php
Resolving example.com (example.com)... xx.xx.xx.xx
Connecting to example.com (example.com)|xx.xx.xx.xx|:443... connected.
ERROR: cannot verify example.com's certificate, issued by ‘/C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Domain Validation Secure Server CA’:
Issued certificate has expired.
To connect to example.com insecurely, use `--no-check-certificate'.
The SSL for the domain is valid and expires in Jan. 2022. Nothing has changed on that front. And yet somehow wget no longer sees that.
Here is another interesting fact. If I run this same exact command on an Ubuntu 18 box, it works like a charm without any complaints. This tells me something is wrong with my Ubuntu 14.04 machine.
Curl produces the same error:
curl https://example.com
curl: (60) SSL certificate problem: certificate has expired
This post suggest that the certificate bundle is out of date. I have downloaded the suggested PEM file and tried running wget with by specifying the --ca-certificate=cacert.pem option, but to no avail.
I have also tried running: apt install ca-certificates and update-ca-certificates, but that did not work either.
Again, everything works great on an Ubuntu 18 box, but not Ubuntu 14 or 16. Also why did it work fine until this morning when I know nobody has touched the box? Clearly something is out of date, but I can't seem to figure out how to fix it.
Does anybody have any suggestions?
I had the same error two days ago with Comodo Certificate and ubuntu 16.04.
The problem was like say mrmuggles this https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA03l00000117LT.
I fixed with this steps:
vi /etc/ca-certificates.conf
Remove the line (or comment)
specifying AddTrust_External_Root.crt
apt update && apt install ca-certificates
update-ca-certificates -f -v
https://askubuntu.com/questions/440580/how-does-one-remove-a-certificate-authoritys-certificate-from-a-system
Like the original poster the method of editing ca-certificates.conf did not work for me on Ubuntu 14.04.
What did work:
Run sudo dpkg-reconfigure ca-certificates
Deselect the problem CA: AddTrust_External_Root
Press OK
My understanding is that deletes the expired CA of AddTrust_External_Root and the newer CA USERTrust_RSA_Certification_Authority is used instead.
For wget add --no-check-certificate
Example: wget https://example.com/resources/scripts/myfile.php --no-check-certificate -O myfile.php
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
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.
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!