Error getting validation data letsencrypt

NGINX Calling page will download strange file + Certbot can’t install certificate

Problem: Certbot returns a urn:ietf:params:acme:error:connection -error when trying to install a certificate for subdomain rainloop.example.com .
EDIT: As to be seen in the «EDIT» segment below there’s a way more important problem, probably the cause of the Certbot failure.

What I´ve tried to solve this issue: I´ve been heavily researching on other people with the same problem, but can´t seem to find any useful information. I´ve looked into my DNS Records for my domain, but since setting up a certificate for my other two subdomains hasn´t been a problem, I´m not questioning this. I´ve also checked the permissions on the root folder of that subdomain and gone through my vhost config multiple times. At last I´ve even restarted my server, but nothing helped.

All Configurations: I´ll end this question by pasting all my configuration files and certbot logs here. Thanks for any answers in advance 🙂

VHOST CONFIGURATION
pfa.example.com (as example, this subdomain works)

rainloop.example.com (subdomain with failed ssl certificate):

I think it´s also important to point out my default vhost config, since I´ve modified it slightly:

Certbot Output during installation:

Certbot log (located at /var/log/letsencrypt/letsencrypt.log ):
Too long to paste it here, have a look at it at my backup page.

Permissions on /var/www/rainloop/: (according to filezilla):

I´m using Debian 9 (Stretch) with NGINX 1.10.3, MariaDB 10.1.37 and PHP 7.2-FPM.

Источник

Unable to issue Let’s Encrypt certificate in Plesk: “Timeout during connect (likely firewall problem)” OR “Error getting validation data”

Symptoms

Unable to install Let’s Encrypt certificate either for a domain example.com in Domains > example.com > Let’s Encrypt or for securing Plesk in Tools & Settings > SSL/TLS Certificates > Let’s Encrypt, with one of the following error messages:

PLESK_ERROR: Detail: Fetching http://example.com/.well-known/acme-challenge/do75fK79n_uF9JimlezVpQQQfmvHaOVd7T8cjZKVvWk: Timeout during connect (likely firewall problem)

PLESK_ERROR: Error: Could not issue a Let’s Encrypt SSL/TLS certificate for example.com. Authorization for the domain failed.
Details:
Invalid response from https://acme-v01.api.letsencrypt.org/acme/authz/dlJ9iUsYRM51xlzLkS8KpRJYccRh1yKRUJEPgLMoRFc.
Details:
Type: urn:acme:error:connection
Status: 400
Details: Fetching https://example.com:8443/.well-known/acme-challenge/44DVtYx2WBKaujKCYO7tOxZ4nS2-m_-Ci5dLoQw0X34 Error getting validation data

PLESK_ERROR: An SSL / TLS certificate could not be issued for example.com
Details
The SSL / TLS Let’s Encrypt certificate could not be issued for example.com . Authorization error for the domain.
Details
Invalid response from https://acme-v02.api.letsencrypt.org/acme/authz-v3/xxxxxx.
Details:
Type: urn: ietf: params: acme: error: connection
Status: 400
Detail: Fetching http://example.com/.well-known/acme-challenge/DOgtM-HLdDLxfaGej39Fip168f6njHhwot47XuyGANo: Error getting validation data

Port 80 and/or port 443 is shown as filtered on IPv4 and/or IPv6 (the below command should be executed on an external PC or server, not on the Plesk server):

# nmap -p 80 example.com
PORT STATE SERVICE
80/tcp filtered http

# nmap -6 -Pn -p80 example.com
PORT STATE SERVICE
80/tcp filtered http

The domain example.com resolves to the IP address of the Plesk server on IPv4 and/or IPv6:

# dig +short example.com
203.0.113.2

# dig +short -t AAAA example.com
2001:db8:f61:a1ff:0:0:0:80

The domain example.com is hosted on the same Plesk server, and only IPv4 address is assigned to it in Domains > example.com > Web Hosting Access.

The following error might be shown when accessing http://example.com in the browser:

Cause

Port 80 and/or 443 is filtered by a firewall.

Resolution

Note: If domain example.com resolves to IPv4 and IPv6, HTTP and HTTPS traffic must be allowed to both networks.

• If the firewall is configured on the Plesk server, open the ports 80 and 443 for incoming connections as described in the article What ports need to be opened for all Plesk Services to work with a firewall
• If Plesk is installed on a public cloud service, follow the instructions to open ports 80 and 443: for Amazon EC2, for Amazon Lightsail, for Google Cloud, for Microsoft Azure, for Alibaba Cloud.
• If some intermediate firewall/router is configured between the Plesk server and an external network, ports 80 and 443 should be opened on it as well.

As alternative solution, when only IPv6 ports are blocked:

Go to Domains > example.com > Web Hosting Access and disable IPv6 address.

Note: If the IPv6 address is defined externally it can be removed on the registrar’s side.

Источник

EPEL SELinux problems #4716

Opening an issue here because I feel better about opening potentially spurious bug reports here than on Bugzilla:

Some users are reporting that SELinux is causing the Apache plugin to fail domain validation challenges on CentOS 7. Doing my own testing, this doesn’t happen with a default configuration. More details can be found at: https://community.letsencrypt.org/t/letsencrypt-suddenly-failing-to-create-temporary-web-root-for-verification/11739

@hogarthj, what do you think?

EDIT: I know very little about SELinux so the testing I thought I did should be ignored as I think I did it wrong.

The text was updated successfully, but these errors were encountered:

I’m configuring selinux to have the certificates in /etc/letsencrypt/(archive|live) correct here but have I missed something happening in /var/lib I need to pay attention to?

I’m not using the apache plugin myself but rather webroot which works fine with this configuration.

If apache needs to serve out of /var/lib/something we should label correctly there so that it will serve up the files — httpd_sys_content_t if memory serves .

At any rate they should not be doing apachectl to restart httpd on CentOS7/Fedora/RHEL7 as that’s not going to be running in the appropriate selinux context or under the supervision of systemd properly.

I really want to get 0.14.1 to stable as updates have been pending a while, but I’ll do some more specific testing of the plugin and get an update prepared for afterwards if I can reproduce.

Okay a quick test of the plugin and I see this:

There’s clearly some issues surrounding selinux being enabled here whilst the apache plugin is used.

I’ll open a ticket in bugzilla as it’s something I’m going to need to look at in some detail (note that I have a certification in selinux policy management and this doesn’t look too painful).

If there’s documentation I can pass back up here or steps that you can incorporate for manual troubleshooting then I’ll add them.

For now the best advice I can give is for the small window of certificate gathering:

I’ll see what I can to make this better in the meanwhile.

I wrote up the files the different Certbot packages access and what they configure other services to access. I can get into more specifics as necessary.

Certbot needs to be able to do whatever it wants with /etc/letsencrypt , /var/lib/letsencrypt , and /var/log/letsencrypt . This applies to both the Apache and Nginx plugins as well. The test output you included above is caused by code in Certbot itself and will apply to all use cases.

The Apache and Nginx plugins largely do the same things to their respective webservers. They need to be able to:

• Read, write, and modify Apache/Nginx configuration files
• Create, call lockf on, and delete a .certbot.lock file in the Apache/Nginx configuration directory.
• Configure Apache/Nginx to include configuration files stored in /etc/letsencrypt
• Configure Apache/Nginx to use certificates and keys stored in /var/lib/letsencrypt (this is done temporarily for domain validation)
• Copy a file from wherever the plugin’s Python source files are (e.g. /usr/lib/python2.7/site-packages/ ) to /etc/letsencrypt .

The Apache plugin also currently configures Apache to use a DocumentRoot in /var/lib/letsencrypt during domain validation, but Apache actually being able to access the files there is unimportant. The only thing that matters is SELinux doesn’t cause Apache to blow up.

any news on this issue?

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:

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

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:

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.

Thanks for the detailed post @davidjb.

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?

Personally I think that Certbot trying to reconfigure an arbitrary SELinux setup so it works properly is complicated and out of scope. What I’d like to see is the packages on systems where SELinux is enabled be modified so Certbot works properly. This can be done using the conventions of the distro rather than Certbot trying to handle any arbitrary configuration.

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.

Since not all systems use systemd (at least not yet), Certbot doesn’t use it to start nginx. Instead, it uses the command nginx -c

-s reload . If nginx isn’t already running, it uses nginx -c

. I’m assuming at least the former command doesn’t fail with this setup? If you have a suggestion for a reliable way we can catch this problem earlier without relying on distro specifics, we’d certainly be open to using that rather our current approach. I’m currently not aware of a way to do that.

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.

Certbot also configures nginx to use these files when getting certs from Let’s Encrypt’s staging server, but Let’s Encrypt does reuse authorizations when you still have a valid one for that domain tied to your account. I suspect this was the cause of the behavior you were seeing. Certbot sets up the challenge, but because Let’s Encrypt didn’t verify it, you got a certificate just fine.

Источник

Problem with letsencrypt certificate

Hi all, through the letsencript plugin I had created the certificate to have an HTTPS connection to my NAS.
The certificate has expired and I can no longer update it, should I have updated it before the deadline?
How can I do now?
It also gives me error messages when creating a new certificate.

From Italy

My NAS: CM Elite 110, Asus P8H77-I, Intel I5 2330, 4GB ram, 1x 4TB HD WDRed, 1x 1TB HD Seagate.
With: Plex, Transmission, SMB, FTP, USBBackup

You need to revert to Http temporaly and delete old cert from NAS, once done you can generate a new cert to use it and revert to https, not know if other way is possible, but this must work because is simmilar to first time you generate the cert.

Tonight, when I come home I try and let you know, thank you!

From Italy

My NAS: CM Elite 110, Asus P8H77-I, Intel I5 2330, 4GB ram, 1x 4TB HD WDRed, 1x 1TB HD Seagate.
With: Plex, Transmission, SMB, FTP, USBBackup

I am having a similar issue right now. I disabled forced HTTPS to renew the certificate, and I got a response that the certificate renewal was successful, but when I checked the certificate information in Chrome, it’s still showing the certificate that is due to expire today.

I am having a similar issue right now. I disabled forced HTTPS to renew the certificate, and I got a response that the certificate renewal was successful, but when I checked the certificate information in Chrome, it’s still showing the certificate that is due to expire today.

This happens on OMV 3 because the private cert is not updated on renewal. Try purging the plugin and reinstalling. OMV 4 shouldn’t have this issue.

omv 6.1.4-1 Shaitan | 64 bit | 6.1 proxmox kernel | plugins :: omvextrasorg 6.1.1 | kvm 6.2.7 | compose 6.5.1 | mergerfs 6.3.4 | zfs 6.0.12
omv-extras.org plugins source code and issue tracker — github

Please try ctrl-shift-R and read this before posting a question.

Please put your OMV system details in your signature.
Please don’t PM for support. Too many PMs!

Okay. I assume I will have to regenerate the certificate once I reinstall it?

I assume I will have to regenerate the certificate once I reinstall it?

omv 6.1.4-1 Shaitan | 64 bit | 6.1 proxmox kernel | plugins :: omvextrasorg 6.1.1 | kvm 6.2.7 | compose 6.5.1 | mergerfs 6.3.4 | zfs 6.0.12
omv-extras.org plugins source code and issue tracker — github

Please try ctrl-shift-R and read this before posting a question.

Please put your OMV system details in your signature.
Please don’t PM for support. Too many PMs!

This happens on OMV 3 because the private cert is not updated on renewal. Try purging the plugin and reinstalling. OMV 4 shouldn’t have this issue.

I think it’s time to move to OMV 4.x then! Is it stable, right? I

Just to not be blocked again next time, the certificates must be updated before the deadline ??

From Italy

My NAS: CM Elite 110, Asus P8H77-I, Intel I5 2330, 4GB ram, 1x 4TB HD WDRed, 1x 1TB HD Seagate.
With: Plex, Transmission, SMB, FTP, USBBackup

Источник

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