Certbot error getting validation data

I am trying to use certbot to add ssl to an already working site (krementimg.us.to) from my server at home. This server runs a node application behind Nginx on Ubuntu 16.04. By following instructions here, my etc/nginx/sites-available/default (my configuration file) looks like this:

server {
    server_name krementimg.us.to;
    client_max_body_size 20M;
    listen 80 default_server;
    listen [::]:80 default_server;    
    root /var/www/html;

    location / {
                proxy_pass http://localhost:443;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection 'upgrade';
                proxy_set_header Host $host;
                proxy_cache_bypass $http_upgrade;
     }
}

Nginx listens on port 80 and directs the client to the application running on port 443. All of this works fine, but, when I run the command sudo certbot --nginx after following the instructions on the certbot website, I get the error

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: krementimg.us.to
   Type:   connection
   Detail: Error getting validation data

   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.

I would like to have ssl on my website, so how can I fix this issue?

Cannot renew let’s encrypt certificates – Error getting validation data

Have you tried renewing your Letsencrypt certificate and got the error below?

root:/etc/letsencrypt/live# certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

The server could not connect to the client to verify the domain

Error getting validation data .

IMPORTANT NOTES:
– The following errors were reported by the server:

Domain: XYZ.com
Type: connection
Detail: Fetching
https://XYZ.com.well-known/acme-challenge/$key:

Error getting validation data

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.

Solution

First check your DNS settings and confirm that no firewalls are preventing the server from communicating with the client. If error persists, check the following:

• Check the website access log. On Apache: /var/log/apache2/XYZ_access.log
• Look out for the entry for Letsencrypt server requests:

66.133.109.36 – – [08/Oct/2018:11:02:04 -0400] “GET /.well-known/acme-challenge/$key HTTP/1.1” 302 642 “-” “Mozilla/5.0 (compatible; Let’s Encrypt validation server; +https://www.letsencrypt.org)”

Note the response code; in this case, 302 – means temporary redirection.

• Check the website configuration file or .htaccess file for any redirection command. In this case, there is a redirection in the site config file @ /etc/apache2/sites-available/XYZ.com.conf:

# redirect http traffic to https

Redirect / https://XYZ.com

• Comment out this line by prepending with #

Service apache2 restart

• Retry the Let’sencrypt certificate renewal

It should be successful now.

• Re-enable the redirection

Источник

I just set up my Server and I cant get my configuration to work with Certbot. It is always the same. I tried some different configurations but none of them worked. This here is my last attempt. It always says: «Error getting validation data» Does anyone have an idea why this does not work?

Full install:

sudo apt-get update && sudo apt-get upgrade

Ign http://ftp.debian.org jessie InRelease
[...]
Processing triggers for initramfs-tools (0.120+deb8u3) ...
Processing triggers for ca-certificates (20141019+deb8u3) ...
Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....done.

sudo apt-get install nano

Reading package lists... Done
[...]
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
[...]
update-alternatives: using /bin/nano to provide /usr/bin/pico (pico) in auto mode

sudo apt install curl

Reading package lists... Done
[...]
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
[...]

sudo mkdir -p /var/www/mydomain.ru/public_html

sudo chown -R root:root /var/www/mydomain.ru/public_html

sudo chmod -R 755 /var/www

nano /var/www/mydomain.ru/public_html/index.html

cd /etc/apache2/sites-available/

/etc/apache2/sites-available# ls

000-default.conf  default-ssl.conf

/etc/apache2/sites-available# cd

sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/mydomain.ru.conf

sudo nano /etc/apache2/sites-available/mydomain.ru.conf

sudo nano /etc/apache2/sites-available/mydomain.ru.conf

sudo a2ensite mydomain.ru.conf
Enabling site mydomain.ru.
To activate the new configuration, you need to run:
  service apache2 reload

sudo a2dissite 000-default.conf
Site 000-default disabled.
To activate the new configuration, you need to run:
  service apache2 reload

sudo a2dissite default-ssl.conf
Site default-ssl already disabled

sudo /etc/init.d/apache2 restart
[ ok ] Restarting apache2 (via systemctl): apache2.service.

sudo nano /etc/apache2/sites-available/mydomain.ru.conf

sudo /etc/init.d/apache2 restart
[ ok ] Restarting apache2 (via systemctl): apache2.service.

sudo nano /etc/apache2/sites-available/mydomain.ru.conf

sudo nano /etc/apt/sources.list

apt-get update
Ign http://ftp.debian.org jessie InRelease
[...]
Reading package lists... Done

sudo apt-get install python-certbot-apache -t jessie-backports
Reading package lists... Done
[...]
0 upgraded, 34 newly installed, 0 to remove and 32 not upgraded.
[...]
Do you want to continue? [Y/n] y
Get:1 http://ftp.debian.org/debian/ jessie-backports/main augeas-lenses all 1.8.0-1~bpo8+1 [422 kB]
[...]
Processing triggers for libc-bin (2.19-18+deb8u10) ...

sudo certbot --apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Which names would you like to activate HTTPS for?
-------------------------------------------------------------------------------
1: mydomain.ru
2: www.mydomain.ru
-------------------------------------------------------------------------------
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel):office@myotherdomain.eu
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org

-------------------------------------------------------------------------------
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf. You must agree
in order to register with the ACME server at
https://acme-v01.api.letsencrypt.org/directory
-------------------------------------------------------------------------------
(A)gree/(C)ancel: a
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for mydomain.ru
tls-sni-01 challenge for www.mydomain.ru
Enabled Apache socache_shmcb module
Enabled Apache ssl module
/usr/lib/python2.7/dist-packages/OpenSSL/rand.py:58: UserWarning: implicit cast from 'char *' to a different pointer type: will be forbidden in the future (check that the types are as you expect; use an explicit ffi.cast() if they are correct)
  result_code = _lib.RAND_bytes(result_buffer, num_bytes)
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. www.mydomain.ru (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Error getting validation data, mydomain.ru (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Error getting validation data

IMPORTANT NOTES:
 - If you lose your account credentials, you can recover through
   e-mails sent to office@myotherdomain.eu.
 - The following errors were reported by the server:

   Domain: www.mydomain.ru
   Type:   connection
   Detail: Error getting validation data

   Domain: mydomain.ru
   Type:   connection
   Detail: Error getting validation data

   To fix these errors, please make sure that your domain name was
[...]
   making regular backups of this folder is ideal.

The changes in my /etc/apache2/sites-available/mydomain.ru.conf

<IfModule mod_ssl.c>
        <VirtualHost mydomain.ru:443>

            ServerAdmin info@mydomain.ru
            ServerName mydomain.ru:443
            ServerAlias www.mydomain.ru
            DocumentRoot /var/www/mydomain.ru/public_html

                # Available loglevels: trace8, ..., trace1, debug, info, notice$
                # error, crit, alert, emerg.
                # It is also possible to configure the loglevel for particular
                # modules, e.g.
                #LogLevel info ssl:warn


                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined

                # For most configuration files from conf-available/, which are
                # enabled or disabled at a global level, it is possible to

I’ve experienced the same issue with the Nginx plugin for Certbot (version 0.18.1) on RHEL 7.4. The symptoms looked like this:

# certbot --nginx --non-interactive
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for example.com
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. example.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Error getting validation data

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: example.com
   Type:   connection
   Detail: Error getting validation data

The issue came down to file contexts on the access/error logs that were being created in /var/lib/letsencrypt/:

-rw-r--r--. root root unconfined_u:object_r:var_lib_t:s0 /var/lib/letsencrypt/access.log
-rw-r--r--. root root unconfined_u:object_r:var_lib_t:s0 /var/lib/letsencrypt/error.log

which means that when Certbot attempted to restart Nginx, it wouldn’t restart because those files couldn’t be accessed and therefore validation failed. The correct context should have been httpd_log_t so I fixed this manually by running the following:

chcon --reference=/var/log/nginx/access.log /var/lib/letsencrypt/access.log
chcon --reference=/var/log/nginx/error.log /var/lib/letsencrypt/error.log

Those /var/lib/letsencrypt/* files appear to persist (and with the correct context) beyond Cerbot’s initial run so hopefully that will stay that way. Is it appropriate for Certbot to be creating those files and setting the SELinux context after reconfiguring Nginx (but before restarting it) or is that out of scope?

Either way, Certbot would be best to confirm that Nginx restarts okay after reconfiguration, which it doesn’t appear to do at present. In my case, nginx -t succeeded in the console (because SELinux doesn’t apply at that point) but an actual systemctl restart nginx failed with permission denied on the /var/lib/letsencrypt/*.log files.

Finally, for note the issue wasn’t a problem on the test CA; that was issuing certificates fine. I haven’t looked into that side of things but I suspect the authorisation was cached or something similar, unless the test configuration generates a different nginx conf that doesn’t touch these log files.

Cannot renew let’s encrypt certificates – Error getting validation data

Have you tried renewing your Letsencrypt certificate and got the error below?

root:/etc/letsencrypt/live# certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

The server could not connect to the client to verify the domain

Error getting validation data .

IMPORTANT NOTES:
– The following errors were reported by the server:

Domain: XYZ.com
Type: connection
Detail: Fetching
https://XYZ.com.well-known/acme-challenge/$key:

Error getting validation data

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.

Solution

First check your DNS settings and confirm that no firewalls are preventing the server from communicating with the client. If error persists, check the following:

• Check the website access log. On Apache: /var/log/apache2/XYZ_access.log
• Look out for the entry for Letsencrypt server requests:

66.133.109.36 – – [08/Oct/2018:11:02:04 -0400] “GET /.well-known/acme-challenge/$key HTTP/1.1” 302 642 “-” “Mozilla/5.0 (compatible; Let’s Encrypt validation server; +https://www.letsencrypt.org)”

Note the response code; in this case, 302 – means temporary redirection.

• Check the website configuration file or .htaccess file for any redirection command. In this case, there is a redirection in the site config file @ /etc/apache2/sites-available/XYZ.com.conf:

# redirect http traffic to https

Redirect / https://XYZ.com

• Comment out this line by prepending with #

Service apache2 restart

• Retry the Let’sencrypt certificate renewal

It should be successful now.

• Re-enable the redirection

Источник

SSL сертификат Lets Encrypt

Здравствуйте. Я так с казать начинающий пользователь битрикса, но с компом давно не на «ВЫ».
Суть.
Виртуалка центос на локальном сервере, не могу установить SSL сертификат Lets Encrypt .

редирект на сайте и включал и выключал.

Развернул другую виртуаллку демо на другом компе/адресе.
Результат тот же.
Хотя прописывал уже другой домен с сертификатом (хотя и тот домен у того же хостинга что и первый)

UPD: пробовал третий сайт другого домена/хостинга. Ошибка та же
UPD: добавил лог

на моем Битрикс24 на самом деле существует, но требует авторизации, что вполне естественно: это же корпоративный портал, а не обычный открытый сайт.

Видимо у ТС ситуация несколько другая и у него все получилось, но как быть таким как я, чтобы получить сертификат для Битрикс24 при отсутствии сайта? Вероятно можно открыть доступ к данной странице без авторизации, но как это сделать, подскажите пожалуйста? Или есть другие варианты решить проблему?

Попробовал поставить CertBot но там получается тоже ерунда, не знаю что ему ответить на вопрос:

Вариант 2 скорее всего не прокатит по той же причине, а вариант 1 что-то стрёмно выбирать — не понятно что за временный вёбсервер он собирается создать и как это повлияет на работу портала?

Источник

Common Certbot Errors

Last updated: July 6th 2022

SSL Certificate Guides

Introduction

Let’s Encrypt is a free and open-source Certificate Authority managed by the Internet Security Research Group. It uses Automated Certificate Management Environment (ACME) server to validate the domain and deploy free SSL certificates automatically that are trusted by all major browsers. The main goal of this project to make encrypted connections throughout the Internet.

Let’s Encrypt provides an easy way to install and deploy SSL certificate for your website for free using a command-line tool called Certbot and is fully supported by Webdock natively in our control panel

Let’s Encrypt Certbot sometimes kicks up a fuss however for a variety of reasons. In this article we document the most commonly encountered errors we see on our platform and how to solve them.

What to always try in Webdock

Regardless of the specific error you are encountering, in 99% of all cases the following operations in Webdock clear things up nicely:

1. Make sure Certbot is up to date, if you are on a Bionic stack or older you should make sure that Certbot runs with the new Snap version. Run the Upgrade Certbot to Snap script on your server, see our article on the subject here.
2. Set the Web Root again, in order to make sure your webserver and Certbot config agree on the location of your web root (access this feature by clicking on the small pencil icon next to the web root as displayed in the Webdock dashboard)
3. Run the Server Identity tool in order to make sure your webserver and Certbot know about all your domains
4. Finally, run the SSL Certificates tool again — now Certbot should complete succesfully in almost all cases

If you are still seeing issues — especially timeout/connection issues on older Ubuntu systems — please try the following as well:

1. Update all packages, by running apt update and apt upgrade
2. Reboot the server, As this may help clear problems with connectivity especially on older Xenial based servers.
3. Finally, run the SSL Certificates tool again

If despite all these common steps which usually resolve Certbot issues you are still having problems — please find your error below and follow our suggestions in order to resolve that specific problem.

Make sure your Certbot installation is up to date

As of late 2020 Certbot is no longer maintained as an apt package and you should make sure it is running through Snap on Ubuntu. This procedure is totally safe and easy to do.

Please read our full article on this topic in order to get up to speed.

Checking if your Let’s Encrypt Certificate is working

Typically Certbot runs fine in Webdock the first time you run it and problems crop up over time or when you do changes to your configuration. Often the first indication you get of a problem is when you get an email from Let’s Encrypt with a title similar to «Let’s Encrypt certificate expiration notice for domain xxx»

When you generate certificates with Webdock we automatically add a Cron job which keeps your certificate up to date. If you get this email then this means your certificate may be about to expire and you need to check if renewals are working.

In Webdock you can simply run the «Test Certbot renewal» script on your server on the Server Scripts page.

What this script essentially does is runs the following command on your server and returns the output so you can inspect what is happening

In the following sections we detail various error messages which may show up here and what to do about them.

Invalid response / The client lacks sufficient authorization

If you get a message similar to the following

Try the suggested fix: Check if your DNS records are OK

First thing to check are your DNS records and whether your A and AAAA records are OK and pointing to your server. However, if your certificate has worked before and you reach your website just fine, then it is unlikely this is the culprit.

However, you should keep an eye on whether there are any web forwards configured (some DNS providers allow this) e.g. if you forward www to non-www or vice-versa, this may trip up Certbot. In which case remove the domain you are forwarding using DNS from your certificate. This should resolve the issue.

To remove a domain in Webdock you simply run Server Identity with the domains you want your webserver to actually respond to and then run the SSL Certificates tool once more.

On Apache: Make sure you exclude Certbot from any .htaccess rewrites

If you are on Apache, check if you have a .htaccess file with rewrites in your web root. If you have such a file you should place a rule to exclude Let’s Encrypt Certbot from any rewrites by placing the exception before any RewriteCond statements. For example:

Once you’ve placed the acme-challenge RewriteRule in there, try running Certbot again.

On Apache: Try rolling back completely and nuking any Certbot config

If your DNS records and rewrites are ok and Certbot renew still fails, you should try and issue the certbot rollback command:

If this gives you errors, try removing the Let’s Encrypt SSL configuration file located at (in default Webdock stacks):

Next run Certbot rollback — and if it succeeds keep running it untill it says it hasn’t touched your configuration. You should now be back to a stock configuration and you should be able to run the SSL Certificates tool once more to generate a new certificate.

If you are not using Webdock and following this guide, you should make sure you back up your configuration before doing this and make sure your config is as you want it and working for vanilla http before running Certbot.

On Nginx: Make sure you exclude Certbot from any deny rules

Similar to Apache, if you have custom configuration which excludes access to hidden directories, such as the following:

You need to add the following rule beofre this in order to allow Certbot to validate using the web root method:

Error while running apache2ctl configtest

This error is related to the last fix detailed above and can be solved in the same manner, if you encounter a message like the following:

Simply delete the old config and try again

During the Webdock Let’s Encrypt SSL installation, a Certbot rollback command hasn’t completely cleared an old default config file. You can resolve this by removing the file /etc/apache2/sites-enabled/000-default-le-ssl.conf and run Certbot once more.

No such file or directory error from Nginx

Sometimes during a Certbot rollback operation or when Certbot tries to renew/install a certificate, Nginx cannot start the webserver as there is till old Certbot configuration hanging around in your Nginx vhost config file. You may see an error like the following:

To solve this issue, remove any references to SSL certificates from your Nginx configuration file. The lines typically look like this:

Once you have removed these lines run Certbot rollback untill it says nothing was modified. If you are using Webdock you would then run the Server Identity tool and finally the SSL Certificates tool and you will now have a shiny new (and working) certificate installed on your server.

If you are not using Webdock, you would likely issue another certbot rollback command and see if it succeeds, next review your config and make sure it is as you want it and that it works for vanilla http, finally you would run Certbot again to generate your certifcate.

Timeout Errors

If you get an error similar to the following:

You need to check whether your DNS records are OK and whether your webserver is listening on your server on port 80 and 443. Make sure you check whether you can ping and ping6 your domain. Typically we see this error happening is if AAAA records for a domain have not been updated, or there are old records pointing to a wrong IP hanging around — but a timeout might also indicate a networking issue (for example a firewall) as stated in the message, or that your server is actively refusing connections for some reason.

Another cause for this issue is that Nginx and Certbot are not aligned as to where your web root is located and Certbot is placing its verification files for web root authentication in the wrong place. A quick way to fix this in Webdock is to simply set the Web Root once more (the small pencil icon next to the web root in the Webdock dashboard) and then run renewal again.

The error may also look something like this:

In our experience, this specific message is due to Let’s Encrypt not being able to connect via. IPv6 — so check that IPv6 works if you have AAAA records for your domain, otherwise all the advice above is also applicable, i.e. check your DNS and connection issues in general. On some older Ubuntu systems (Xenial especially) a general package upgrade with apt update and apt upgrade has been seen by us as an easy resolution to some ipv6 connection issues.

Connection Refused Error

If you get a Connection Refused error when doing renewals, this may be due to old-style Certbot configuration not having written the appropriate configuration to your Nginx config in order to allow Nginx to listen on your IPv6 address. You would typically see an error like the following:

What this error really is saying is: Certbot could not connect to your domain on port 443. Typically what we see is that if you now check what is listening on which ports by running netstat you will get something like the following:

Notice how nginx is listening on tcp (ipv4) port 443 but not tcp6 (ipv6) ? This is the problem as the Let’s Encrypt certificate servers prefer to connect through ipv6 if there are AAAA records set up for your domain.

In order to solve this, check that you have the following line in your Nginx config (on Webdock servers the vhostconfig file is typically found at /etc/nginx/sites-enabled/webdock) , and if not, add it:

Next, restart Nginx:

Check that nginx is listening on tcp6 port 443 and try your renewal again. It should work this time — but if not, then make sure nginx is listening on the appropriate interfaces and on both ports 80 and 443 and is reachable from the outside, because if it is not you will get this error message.

Account creation on ACMEv1 is disabled

If you get an error message similar to the following

This simply means that the installed version of Certbot is too old and doesn’t support newer authentication methods. Simply upgrade your system with:

If it prompts you what to do about existing config files just choose the defaults which is to keep the existing configuration. Once the system is upgraded it is a good idea to reboot the system, or at the very least your webserver and php-fpm before trying again.

Please note: During the system upgrade your webserver will likely go down temporarily. Plan accordingly.

The request message was malformed

Similarily an indication your Certbot is too old may be seen from the following Certbot output:

The solution here is, as with the error above, to upgrade your system. The same warning applies: upgrading may bring down your webserver temporarily.

Test Certbot Renewal script hangs for a long time, prompts for a new webroot in output

Sometimes Webdock users experience that the Test Certbot renewal scripts hangs for a long time and then outputs something similar to the following:

This is due to Certbot having «forgotten» what the appropriate web root is for your domain. We use web root authentication in order to avoid certain other issues with Cloudflare and Cloudflare caching. In any case, the solution here is to set the web root once more on your server, after which you should run the SSL Certificates tool once more. If you still get errors, try running the Server Identity tool first.

We have servers in:

Источник