Failed authorization procedure. www..com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://domain.com/.well-known/acme-challenge/<#hash>: Connection reset by peer, domain.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://domain.com/.well-known/acme-challenge/<#hash>: Connection reset by peer.
This seems to be a chicken and egg problem. It’s trying to validate via https, but https isn’t working because there’s no certificate, which is what this is supposed to do.
No, the http-01 challenge performed by webroot initiates over HTTP, you must have a redirect somewhere pointing it to HTTPS.
This is one of those problems that is very difficult to provide any form of meaningful help for without the domain in question. Would you please post your real domain name?
Temporarily disable the redirect from HTTP to HTTPS.
Exclude /.well-known/acme-challenge/ from the redirect.
Temporarily configure some sort of certificate. It doesn’t have to be valid. For example, a self-signed certificate, or a Let’s Encrypt certificate for a different domain, will do.
If using Apache or Nginx, try “certbot --apache” or “certbot --nginx”.
", realcanetalk.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://realcanetalk.com/.well-known/acme-challenge/hMQFrC1SPdE36FINQb7GUwXHPbM3-9BvAcLt9gUrjH4: "
404 Not Found
404 Not Found
"
config:
server {
listen 80 default_server; #rewrite ^ https://$server_name$request_uri? permanent; #listen [::]:80 default_server;
server_name realcanetalk.comwww.realcanetalk.com;
# SSL configuration
#
# listen 443 ssl http2;
# listen [::]:443 ssl default_server;
#
# Note: You should disable gzip for SSL traffic.
# See: https://bugs.debian.org/773332
#
# Read up on ssl_ciphers to ensure a secure configuration.
# See: https://bugs.debian.org/765782
#
# Self signed certs generated by the ssl-cert package
# Don’t use them in a production server!
# #include snippets/snakeoil.conf; #root /var/www/html;
root /usr/share/nginx/html;
# Add index.php to the list if you are using PHP
index index.php index.html index.htm index.nginx-debian.html;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
location ~ .php$ {
include snippets/fastcgi-php.conf;
# # With php7.0-cgi alone:
# fastcgi_pass 127.0.0.1:9000;
# # With php7.0-fpm:
fastcgi_pass unix:/run/php/php7.0-fpm.sock;
}
# deny access to .htaccess files, if Apache’s document root
# concurs with nginx’s one
#
location ~ /.ht {
deny all;
}
location ‘/.well-known/acme-challenge’ {
default_type “text/plain”;
allow all;
}
}
It’s possible that --standalone worked because you didn’t have an existing port 443 listener, but once you do, it’s possible that renewals with that continue using --standalone will fail because it will be unable to bind port 443.
If you want to use --webroot, your correct webroot is probably /usr/share/nginx/html rather than /.