i'm trying of get a ssl with let's encrypt, i have nginx and nodejs but when i type this comand "sudo certbot --nginx -d simca.tech" appear this:
Failed authorization procedure. simca.tech (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://simca.tech/.well-known/acme-challenge/Kmjz6pdfz91ubRRrE_AL-qQ5Z-1FB7vfM3WSt6xuul8 [104.248.66.200]: "<!doctype html>\n<html lang=\"en\">\n<head>\n <meta charset=\"utf-8\">\n <title>Cliente</title>\n <base href=\"/\">\n\n <meta name=\"viewp"
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: simca.tech
Type: unauthorized
Detail: Invalid response from
http://simca.tech/.well-known/acme-challenge/Kmjz6pdfz91ubRRrE_AL-qQ5Z-1FB7vfM3WSt6xuul8
[103.xxx.65.xxx]: "<!doctype html>\n<html lang=\"en\">\n<head>\n
<meta charset=\"utf-8\">\n <title>Cliente</title>\n <base
href=\"/\">\n\n <meta name=\"viewp"
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.
Related
I am trying to install a Let's Encrypt SSL certificate to a subscription held on a Plesk install.
I am running the following version of Plesk;
Plesk Onyx Version 17.8.11 Update #11
I then navigate to
Subscriptions > Domain > Lets Encrypt
From the setup screen I do not change anything, so
'Include a "www" subdomain for the domain and each selected alias'
and
'Secure webmail on this domain'
Remain unchecked. However, when I try to install the cert I get the following error;
Error: Could not issue a Let's Encrypt SSL/TLS certificate for domain.org.
The authorization token is not available at http://example.com/.well-known/acme-challenge/key.
The token file 'C:\Inetpub\vhosts\example.com\httpdocs\\.well-known\acme-challenge\key' is either unreadable or does not have the read permission.
To resolve the issue, correct the permissions on the token file to make it is possible to download it via the above URL.
See the related Knowledge Base article for details.
Details
Invalid response from https://acme-v01.api.letsencrypt.org/acme/authz/umis0L7-OVlu7SrSjMFHBsu-T7Cx0hwFS-WMxHgZgNA.
Details:
Type: urn:acme:error:unauthorized
Status: 403
Detail: Invalid response from http://example.com/.well-known/acme-challenge/key: "<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-sc"
It give a link to the following KB;
Plesk Suggested KB article
Which suggest I check the DNS resovles, so ipconfig shows me that the domain is pointing to the right IP.
However I dont have the ability for IPv6 and when i go to
domains > example.com> Web Hosting Access
I do not have the ability to select this.
Now from RDP to the server and looking I can see the directory structure is created i..e
.well-known > acme-challenge > key file
is created? Can anyone help with what the issue could be here please?
Check if the domain name resolves to IPv6 or not:
dig AAAA google.com #8.8.8.8
Check permissions for token file well-known > acme-challenge > key file
Try to access this file via browser, or create a new test text file inside of the acme-challenge folder and try to access it. There is a possibility that web.config file can cause the issue.
I'm running plesk 17 on a debian machine. One certificate could be signed without problems. But then I got this error:
Error: Let's Encrypt SSL certificate installation failed: Failed letsencrypt execution: Saving debug log to /opt/psa/var/modules/letsencrypt/logs/letsencrypt.log
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for mindmailer.de
http-01 challenge for www.mindmailer.de
Starting new HTTPS connection (1): 127.0.0.1
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. mindmailer.de (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://mindmailer.de/.well-known/acme-challenge/Zg70UTECV4lP-E25ateUev3vsq5nCbX-4L-KUXwUU4I: "<!DOCTYPE html>
<html lang="de" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta charset="utf-8">
<!--
This website is powe", www.mindmailer.de (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.mindmailer.de/.well-known/acme-challenge/rreVCbEY8pX5eaWVMGiZsg2UxNennZfwkHC6WMAJV-Q: "<!DOCTYPE html>
<html lang="de" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta charset="utf-8">
<!--
This website is powe"
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: mindmailer.de
Type: unauthorized
Detail: Invalid response from
http://mindmailer.de/.well-known/acme-challenge/Zg70UTECV4lP-E25ateUev3vsq5nCbX-4L-KUXwUU4I:
"<!DOCTYPE html>
<html lang="de" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta charset="utf-8">
<!--
This website is powe"
Domain: www.mindmailer.de
Type: unauthorized
Detail: Invalid response from
http://www.mindmailer.de/.well-known/acme-challenge/rreVCbEY8pX5eaWVMGiZsg2UxNennZfwkHC6WMAJV-Q:
"<!DOCTYPE html>
<html lang="de" xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta charset="utf-8">
<!--
This website is powe"
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address.
What could be the problem in this case?
DNS A records are on the right ip adress .. Any ideas?
Thanks
You have redirects, which conflicts with the Let's Encrypt - challenge ( => "marketing.mindmailer.de" ) and as you can see in your error - log, Let's Encrypt tries to write to "mindmailer.de/.well-known/acme-challenge/", which is not possible this way.
I know this question has been asked several times, but I need some specific help as I've been taking advice from several other threads and nothing has worked to this point.
I'm trying to renew my SSL certificate in Ubuntu 14.04 using certbot-auto renew, and I'm running an Apache2 server and nginx. I'm getting the following output for certbot-auto renew:
root#PostgreSQLServer:/# sudo certbot-auto renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log
-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/my-domain.com.conf
-------------------------------------------------------------------------------
Cert is due for renewal, auto-renewing...
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for my-domain.com
Waiting for verification...
Cleaning up challenges
Attempting to renew cert from /etc/letsencrypt/renewal/my-domain.com.conf produced an unexpected error: Failed authorization procedure. my-domain.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://my-domain.com/.well-known/acme-challenge/ailNmgZADpb4QBipKM57sOi9w3PwNkwBwVFiRYs7i40: "<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p". Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/my-domain.com/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: my-domain.com
Type: unauthorized
Detail: Invalid response from
http://my-domain.com/.well-known/acme-challenge/ailNmgZADpb4QBipKM57sOi9w3PwNkwBwVFiRYs7i40:
"<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p"
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address.
I ensured the .well-known folder exists in /var/www/my-domain.com/public_html and when I navigate to http://my-domain.com/.well-known/ in my browser, I am able to see the contents of that directory. I also added an acme-challenge folder in .well-known and included a test.txt file for testing; I was able to access the directory and the text file in my browser.
I found that the acme-challenge folder was not created when I ran the certbot-auto command so it seems to be a permissions issue. I am running certbot-auto as root, but also gave write permissions to www-data user on the .well-known and acme-challenge folders (root and www-data users are running the apache2 and nginx processes).
Even after granting that write permission, I still get the 404 error detailed above.
I also have an automated cert renewal process running via crontab and I have the output being logged to a local file. In that log file, I see the renewal request seemed to be working correctly until certbot-auto was upgraded from 0.9.3 to 0.10.1. Here's a sample from the log file when the upgrade took place:
-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/offensively-bad.com.conf
-------------------------------------------------------------------------------
The following certs are not due for renewal yet:
/etc/letsencrypt/live/offensively-bad.com/fullchain.pem (skipped)
No renewals were attempted.
-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/offensively-bad.com.conf
-------------------------------------------------------------------------------
The following certs are not due for renewal yet:
/etc/letsencrypt/live/offensively-bad.com/fullchain.pem (skipped)
No renewals were attempted.
Upgrading certbot-auto 0.9.3 to 0.10.1...
Replacing certbot-auto...
Creating virtual environment...
Installing Python packages...
Installation succeeded.
-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/offensively-bad.com.conf
-------------------------------------------------------------------------------
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/offensively-bad.com/fullchain.pem (failure)
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: offensively-bad.com
Type: unauthorized
Detail: Invalid response from
http://offensively-bad.com/.well-known/acme-challenge/tkSc8l-r1XVPIF5TosTbEXiYMa8sQnoXEjAEgAwRoqI:
"<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p"
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address.
You can see that after upgrading, the process began failing with a 404 message.
I've tried all the advice I could find online and am completely stumped, so any help would be much appreciated. Thanks in advance!
My problem was a too old certbot version on my raspberry pi raspbian Stretch:
certbot --version
Gave
certbot 0.10.2
apt-get install python-certbot-apache -t stretch-backports
Did the trick:
certbot 0.21.1
And then just
certbot --apache -d domain.com
Hope this helps!
I had to edit this conf file: /etc/letsencrypt/renewal/offensively-bad.com.conf and modify the line below [[webroot_map]]:
[[webroot_map]]
offensively-bad.com = /path/to/what/certbot/thinks/is/the/correct/webroot/path/initially/specified/by/the/user
In my case, I changed it to
offensively-bad.com = /var/www/offensively-bad.com/public_html/
Thanks to the forum at letsencrypt for helping me out.
While generating the Reports under payroll module in local odoo server - I am getting the following error:
Odoo
XmlHttpRequestError Proxy Error
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>502 Proxy Error</title>
</head><body>
<h1>Proxy Error</h1>
<p>The proxy server received an invalid
response from an upstream server.<br />
The proxy server could not handle the request <em>POST /web/dataset/call_button</em>.<p>
Reason: <strong>Error reading from remote server</strong></p></p>
<hr>
<address>Apache/2.4.7 (Ubuntu) Server at 192.168.111.188 Port 80</address>
</body></html>
I have the same problem when i try to create a new db
odoo 8.0.17 / bitnami stack
> XmlHttpRequestError Proxy Error <!DOCTYPE HTML PUBLIC "-//IETF//DTD
> HTML 2.0//EN"> <html><head> <title>502 Proxy Error</title>
> </head><body> <h1>Proxy Error</h1> <p>The proxy server received an
> invalid response from an upstream server.<br /> The proxy server could
> not handle the request <em><a
> href="/web/database/create">POST /web/database/create</a></em>.<p>
> Reason: <strong>Error reading from remote server</strong></p></p>
> </body></html>
Try these steps to solve the XmlHttpRequestError Proxy Error:
It is something related to browser end only so use Private Window
Clear Browser cookie because sometimes cookies are corrupted
Some times page actually loading but request time out
It Works For Me try this, you have to update your action module code(for example - model:employee.fine) with empty print statement or something else, now try that action again it works!
We have logger adapter "WLClientLogReceiver". When we tried to hit the REST service using below link to get adapter details we got 404 error
https://example.com/worklightadmin/management-apis/1.0/runtimes/myruntimename/adapters/WLClientLogReceiver
Respnse:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /worklightadmin/management-apis/1.0/runtimes/myruntimename/adapters/WLClientLogReceiver was not found on this server.</p>
<hr>
<address>IBM_HTTP_Server at example.com Port 443</address>
</body></html>
The 404 seems to suggest the URL is wrong. If the URL were indeed proper , then a message such as - " The adapter \"WLClientLogReceiver\" of the runtime \"yourruntime\" does not exist in the MobileFirst administration database" is returned, in case you query for a missing adapter.
To test:
a)
The URL - "https://example.com/worklightadmin/management-apis/1.0/runtimes/myruntimename/adapters?" returns metadata of all deployed adapters.
Check if you get the list of all adapters and see if WLClientLogReceiver is in the list.
b) If that also gives you a 404 :
If you are deployed on a standalone server, your admin context might be different - for standalone servers ,it is by default "wladmin" as opposed to "worklightadmin" in the Development server. Verify your context root.