I run
docker-compose run certbot -d *.domain1.com -d *.domain2.com --manual --preferred-challenges dns certonly
However when I press enter too early I get the following error
The following errors were reported by the server:
Domain: domain1.com
Type: None
Detail: DNS problem: NXDOMAIN looking up TXT for
_acme-challenge.domain1.com
When running the command again I get new challenge keys. I would like to retry until my DNS record are "live" (DNS server is up to date).
It appears there is no way to renew a certificate by DNS challenge, without adding a new TXT record.
https://community.letsencrypt.org/t/renewing-with-dns-challenge/37184
https://serverfault.com/questions/879647/renew-domains-using-certbot-and-using-dns-challenge
Related
This question shows research effort; it is useful and clear
I have checked the cURL not working properly
When I run the command curl -I https://www.example.com/sitemap.xml
curl: (7) Failed to connect
Failed to connect on all port
this error only on one domain, all other domain working fine, curl: (7) Failed to connect to port 80, and 443
Thanks...
First Check your /etc/hosts file entries, may be the URL which You're requesting, is pointing to your localhost.
If the URL is not listed in your /etc/hosts file, then try to execute following command to understand the flow of Curl Execution for the particular URL:
curl --ipv4 -v "https://example.com/";
After many search, I found that Hosts settings not correct
Then I check nano /etc/hosts
The Domain point to wrong IP in hosts file
I change the wrong IP and its working Fine
This is new error Related to curl: (7) Failed to connect
curl: (7) Failed to connect
The above error message means that your web-server (at least the one specified with curl) is not running at all — no web-server is running on the specified port and the specified (or implied) port. (So, XML doesn't have anything to do with that.)
you can download the key with browser
then open terminal in downloads
then type sudo apt-key add <key_name>.asc
Mine is Red Hat Enterprise(RHEL) Virtual Machine and I was getting something like the following.
Error "curl: (7) Failed to connect to localhost port 80: Connection refused"
I stopped the firewall by running the following commands and it started working.
sudo systemctl stop firewalld
sudo systemctl disable firewalld
If the curl is to the outside world, like:
curl www.google.com
I have to restart my cntlm service:
systemctl restart cntlm
If it's within my network:
curl inside.server.local
Then a docker network is overlapping something with my CNTLM proxy, and I just remove all docker networks to fix it - you can also just remove the last network you just created, but I'm lazy.
docker network rm $(docker network ls -q)
And then I can work again.
I'm building an app in Laravel that has a single codebase that will serve multiple domain names, a new domain can be added in the CMS, and all that should have to be done for that new domain to work is have it's records pointed to the server. The CMS itself will then display the appropriate pages for that domain, based on the request()->getHost(); function.
The app is being managed with Laravel Forge.
My question is regarding nginx, and LetsEncrypt: I would like all new domains added in this way to be secured via SSL, would every new domain need to be added to forge manually, or is there some way to allow a wildcard TLD in the certificate? (And if so, is that a security risk?).
Will nginx require some specific configuration to work with wildcard TLDs?
My aim is to avoid additional configuration and have it automatic, with the domain name simply being added to the backend.
Thanks!
Please follow the Steps. Hope it will work for you.
1 - First clone Letsencrypt/Certbot repo from Github
cd /opt
git clone https://github.com/certbot/certbot.git
2 - Now enter new created directory and run certificate bot
cd certbot
./letsencrypt-auto certonly --manual --preferred-challenges=dns --email mymail#gmail.com --server https://acme-v02.api.letsencrypt.org/directory --agree-tos -d *.mywebsite.com
3 - Now Certbot will ask for a DNS record to check that if you really have rights at this domain.
------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.mywebsite.com with the following value:
5GFgEqWd7AQrvHteRtfT5V-XXXXXXXXXXXXXX
Before continuing, verify the record is deployed.
------------------------------------------------------------------
Press Enter to Continue
4 - After adding this DNS TXT record to your domain and wait for few seconds press enter and continue.
5 - Your certificate is ready!
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/mywebsite.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/mywebsite.com/privkey.pem
Your cert will expire on 2018-08-22. To obtain a new or tweaked
version of this certificate in the future, simply run certbot-auto
again. To non-interactively renew *all* of your certificates, run
"certbot-auto renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
6 - Now we will copy our fullchain.pem and privkey.pem to our Nginx folder and add this to our Nginx server configuration. For example;
server {
listen 443 ssl;
server_name test.mywebsite.com;
ssl_certificate /etc/nginx/ssl/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/privkey.pem;
ssl_trusted_certificate /etc/nginx/ssl/fullchain.pem;
...
Hope it will helpful.
This is my first time working with Laravel, and I have a project set up, but I cannot connect to the database I created in Postgres. Whenever I try to connect to the database for a query (or anything), I get this error:
PDOException
SQLSTATE[08006] [7] FATAL: password authentication failed for user "marlie" FATAL: password authentication failed for user "marlie"
I'm using Windows 10, PostgreSQL 11, Laravel 6.0.4. I can connect to the database through pgAdmin4, command line, and psycopg2 without any password authentication issues. Only Laravel is giving me a hard time.
I've tried creating a new Laravel project, creating a new superuser (which I've tested, can successfully access the database from the other programs I mentioned above). I've also tried putting the username and password in both single and double quotes. I tried changing the database name to the OID number value in my postgreSQL file for the database. I've also tried adding the absolute file directory. I've tried changing port from 5432 to 54320. I've also tried other passwords.
Some search results suggested I play with the pg_hba.conf file and adding some lines such as (the indentation here is a little funny, but in the actual file it's all lined up):
local all marlie md5
local all marlie trust
host all all ::1/0 trust
host all all all trust
I've also tried changing everything to trust, in which case I can log in from command line without a password, but Laravel still won't let me! Also, my Windows laptop doesn't seem to support local connections since they're Unix-socket domains, so any local entries in pg_hba.conf end with the file not being able to load at all. Currently, my pg_hba.conf file is back to the default settings.
I've tried logging in by ssh into my Laravel project through Homestead.
$ vagrant ssh
$ psql -d natureFun -U marlie -W
Password:
psql: FATAL: Peer authentication failed for user "marlie"
I thought this was interesting because nowhere in my conf file do I say to use peer authentication. I've only ever tried trust and md5.
This is my .env file from Laravel
DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE=natureFun
DB_USERNAME=marlie
DB_PASSWORD=secret
This is pg_hba.conf
# TYPE DATABASE USER ADDRESS METHOD
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all 127.0.0.1/32 md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
host replication all 127.0.0.1/32 md5
host replication all ::1/128 md5
It seems that your first pg_hba.conf has a typo:
host all all all trust
Should be:
host all all <ip_address>/<netmask> trust
If it's a dev machine and you don't care about security (for now), just try:
host all all 0.0.0.0/0 trust
Also, unless you're acutally using IPv6, I'd recommend getting rid of the entire line containing ::1/0
Your second pg_hba.conf that you pasted should work, given that you restarted/reloaded the postmaster process -- you can usually do that through pg_ctl reload from the terminal or SELECT pg_reload_conf() from psql
Disclosure: I am an EnterpriseDB (EDB) employee
SOLVED! I misunderstood how Homestead worked (and also failed to mention that I am using it, sorry!)
when I put localhost or 127.0.0.1 in my .env file in my Laravel project, it references the Homestead Virtual as the localhost, NOT my actual computer.
Changing DB_HOST to my computer's IP address solved the problem and I am now happily connected.
I am trying to generate certificate for my domain. I can ping my domain but still getting error. I have added inbound firewall rule to my digital ocean server to accept port 80 on ipv4 and ipv6 as well. Not sure what is wrong. [Note: my nginx server is not running as I cannot get the certificate]
https://community.letsencrypt.org/t/invalid-response-404-nginx-docker-container/102525
My domain is: www.1040nra.com
I ran this command: sudo certbot certonly --staging --webroot -w /root/dt-app-data/ -d 1040nra.com -d www.1040nra.com
It produced this output:
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for 1040nra.com
http-01 challenge for www.1040nra.com
Using the webroot path /root/dt-app-data for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. 1040nra.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://1040nra.com/.well-known/acme-challenge/22AD-KFmF62z373CPiUKzk6dlr-0s5wMOmnmrziMqd4: Connection refused, www.1040nra.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://www.1040nra.com/.well-known/acme-challenge/ba-jjDhBUZJ9fHLofGfDYSVV5a-ETlX26A64A-2Yu0s: Connection refused
IMPORTANT NOTES:
The following errors were reported by the server:
Domain: 1040nra.com
Type: connection
Detail: Fetching
http://1040nra.com/.well-known/acme-challenge/22AD-KFmF62z373CPiUKzk6dlr-0s5wMOmnmrziMqd4:
Connection refused
Domain: www.1040nra.com
Type: connection
Detail: Fetching
http://www.1040nra.com/.well-known/acme-challenge/ba-jjDhBUZJ9fHLofGfDYSVV5a-ETlX26A64A-2Yu0s:
Connection refused
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you’re using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
My web server is (include version):
The operating system my web server runs on is (include version): ubuntu 18.04
You seem to have solved the problem yourself.
This is because the certbot domain cannot verify the DNS A record.
Make sure your domain address is directed to your server's ip address.
If you made the dns change 'recently', it may take some time to delete the old ip address.
https://www.whatsmydns.net/
Check here, there should only be one IP address and this should be your server's IP address.
Make sure ports 80 and 443 are open by running the command below:
sudo ufw status
If port 443 is not open, then run the command bellow to allow port 443:
sudo ufw allow https
Issue: The issue is your domain might be not pointing to your Cloud host IP and DNS setup
Solution:
You have to map your domain and IP in-network option tab A
Once you did the mapping then you have to setup DNS on where you have purchased the domain website.
Then check by entering your domain name on this web site www.whatsmydns.net showing your IP address or not
If Yes then you create the certificate
Go to the https://www.whatsmydns.net/
Enter your host name
You set the type A
Make sure that there is the same IP everywhere
You set the type AAAA
Make sure there are no AAAA entries
AAAA are IPv6 entries.
If the addresses for AAAA are present, make a request to this IPv6 address
#example curl [43ff:0c89:eb10:4c06:c90e:4b7d:64e5:fbe1]
curl [your IPv6]
If you get an error, then the address does not point to your site. Accordingly, there is a difference between IPv4 and IPv6.
Solution: delete the domain zone type AAAA
The full error message I'm getting is:
Attempting to renew cert from /etc/letsencrypt/renewal/somedomain.com.conf produced an unexpected error: Problem binding to port 443: Could not bind to IPv4 or IPv6.. Skipping.
This is running on an AWS ubuntu 14.04 instance. All ports are open outgoing and 443 is open incoming.
You just need to stop all running servers like Apache, nginx or OpenShift before doing this.
Stop Nginx
sudo systemctl stop nginx
Stop Apache2
sudo systemctl stop apache2
you probably run the script with (preconfigurated) --standalone when your server is already running at port 443.
You can stop server before renew and start them after.
man says:
--apache Use the Apache plugin for authentication & installation
--standalone Run a standalone webserver for authentication
--nginx Use the Nginx plugin for authentication & installation
--webroot Place files in a server's webroot folder for authentication
--manual Obtain certificates interactively, or using shell script hooks
If I run renew with --apache I can't get any error.
As hinted in the other answers, you need to pass the option for your running webserver, for example:
Without webserver param:
sudo certbot renew
Cert is due for renewal, auto-renewing...
Renewing an existing certificate
Performing the following challenges:tls-sni-01 challenge for example.com
Cleaning up challenges
Attempting to renew cert (example.com) from /etc/letsencrypt/renewal/example.com.conf produced an unexpected
error:
Problem binding to port 443: Could not bind to IPv4 or IPv6..
Skipping.
Then, again with the webserver param (success):
sudo certbot renew --nginx
Cert is due for renewal, auto-renewing...
Renewing an existing certificate
Performing the following challenges: tls-sni-01 challenge for example.com
Waiting for verification...
Cleaning up challenges
new certificate deployed with reload of nginx server; fullchain is
/etc/letsencrypt/live/example.com/fullchain.pem
Congratulations, all renewals succeeded. The following certs have been
renewed: /etc/letsencrypt/live/example.com/fullchain.pem (success)
[This is specifically for ubuntu]
Login as root user to your server
Stop your server using the following command (for nginx)
service nginx stop
Then renew your certificate
certbot renew
Start your server
service nginx start
[TIP] To check the expiry date of your renewed certificate, enter the command below
ssl-cert-check -c [Path_to_your_certificate]/fullchain.pem
For example
ssl-cert-check -c /etc/letsencrypt/live/[your_domain_name]/fullchain.pem
Or
ssl-cert-check -c /etc/letsencrypt/live/[your_domain_name]/cert.pem
If you don't have ssl-cert-check already installed in your server, install it using
apt install ssl-cert-check
Note: The certificate can be renewed only if it is not expired. If it is expired, you have to create new one.
For NodeJS/PM2 users
I was using PM2 for my NodeJS service and when trying to renew the certificate I also got the "Problem binding to port 80: Could not bind to IPv4 or IPv6." error message.
As mentioned in above answers for Apache/Ngnix, Stopping my service and then trying to renew solved the problem.
pm2 stop all
sudo certbot renew
pm2 start all
First you need to install NGiNX lets encrypt plugin (if you work with NGiNX):
sudo apt install python-certbot-nginx
Then you can safely run:
sudo certbot renew --nginx
and it will work.
Note: certbot should already be installed.
For ngnix
sudo certbot renew --nginx
This happened because you used --standalone. The purpose of that option is to launch a temporary webserver because you don't have one running.
Next time use the --webroot method, and you'll be able to use your already running nginx server.
Borrowing from #JKLIR Simply run
/etc/letsencrypt/letsencrypt-auto renew --apache >> /var/log/letsencrypt/renew.log
to renew the ssl certificate
If you're trying to perform the certbot command as a regular user, you may not have access to bind to port 80 and other lower ports. If this is the case, you can grant python access to bind via:
First, see if you can find python 3+ (adjust as needed)
echo "$(readlink -f "$(which python3)")"
Allow python to open port 80 as a regular user (adjust as needed)
sudo setcap CAP_NET_BIND_SERVICE=+eip "$(readlink -f "$(which python3)")"
Re-run the failing certbot command.
Important: On Ubuntu 18.04, Python is called python3. It may be called a number of different things depending on the OS and how you obtained certbot. This command WILL VARY between OSs.
Warning: These lower ports are restricted for good reason. There are security considerations with the setcap command. You may read more about them here: https://superuser.com/a/892391
I use Nginx and needed to stop the server before I can proceed. Then I run the command:
$ sudo ./certbot-auto certonly --standalone -d chaklader.ddns.net
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for chaklader.ddns.net
Waiting for verification...
Cleaning up challenges
Subscribe to the EFF mailing list (email: xxx.chakfffder#gmail.com).
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/cdddddder.ddns.net/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/chaklader.ddns.net/privkey.pem
Your cert will expire on 2045-01-10. To obtain a new or tweaked
version of this certificate in the future, simply run certbot-auto
again. To non-interactively renew *all* of your certificates, run
"certbot-auto renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
I had a similar issue when I was running two websites (hosts) on a single instance. I stopped Nginx and then ran sudo certbot certonly --standalone --preferred-challenges http -d domain.com -d www.domain.com. After restarting Nginx everything started to work fine.