ERROR: unauthorized -- Invalid response from

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: maafascreamsnews.com

I ran this command:

certbot certonly \
    --standalone \
    --key-path /etc/letsencrypt/live/maafascreamsnews.com \
    --fullchain-path /etc/letsencrypt/live/maafascreamsnews.com \
    -d maafascreamsnews.com \
    -d dev.maafascreamsnews.com \
    -d uat.maafascreamsnews.com \
    -d www.maafascreamsnews.com \
    --non-interactive \
    --preferred-challenges http \
    --agree-tos \
    --force-renewal \
    --email hesco@yourmessagedelivered.com \
    --http-01-port=8888

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log 
Plugins selected: Authenticator standalone, Installer None 
Attempting to parse the version 0.36.0 renewal configuration file found at /etc/letsencrypt/renewal/crm.www.wp.tns.gagreenparty.org.conf with version 0.31.0 of Certbot. This might not work. 
Attempting to parse the version 0.36.0 renewal configuration file found at /etc/letsencrypt/renewal/openproject.yourmessagedelivered.com.conf with version 0.31.0 of Certbot. This might not work. 
Obtaining a new certificate 
Performing the following challenges: 
http-01 challenge for maafascreamsnews.com 
http-01 challenge for www.maafascreamsnews.com 
Waiting for verification... 
Cleaning up challenges 
Failed authorization procedure. maafascreamsnews.com (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from https://maafascreamsnews.com/.well-known/acme-challenge/8UI_5BlYTx-r3QqLD5CbRxDzLSCBtHVONgLPAH5TxbI [209.195.11.75]: "<!DOCTYPE html>\n<html lang=\"en\" dir=\"ltr\" prefix=\"content: http://purl.org/rss/1.0/modules/content/  dc: http://purl.org/dc/term", www.maafascreamsnews.com (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from https://www.maafascreamsnews.com/.well-known/acme-challenge/Dcv57pkr37WTSA_WGWm4fNoQVwWgYCD6InzkrmhLmoY [209.195.11.75]: "<!DOCTYPE html>\n<html lang=\"en\" dir=\"ltr\" prefix=\"content: http:/purl.org/rss/1.0/modules/content/  dc: http://purl.org/dc/term"

IMPORTANT NOTES: 
 - The following errors were reported by the server: 
   Domain: maafascreamsnews.com 
   Type:   unauthorized 
   Detail: Invalid response from 
   https://maafascreamsnews.com/.well-known/acme-challenge/8UI_5BlYTx-r3QqLD5CbRxDzLSCBtHVONgLPAH5TxbI 
   [209.195.11.75]: "<!DOCTYPE html>\n<html lang=\"en\" dir=\"ltr\" 
   prefix=\"content: http://purl.org/rss/1.0/modules/content/  dc: 
   http://purl.org/dc/term" 

   Domain: www.maafascreamsnews.com 
   Type:   unauthorized 
   Detail: Invalid response from 
   https://www.maafascreamsnews.com/.well-known/acme-challenge/Dcv57pkr37WTSA_WGWm4fNoQVwWgYCD6InzkrmhLmoY [209.195.11.75]: "<!DOCTYPE html>\n<html lang=\"en\" dir=\"ltr\" 
   prefix=\"content: http://purl.org/rss/1.0/modules/content/  dc: http://purl.org/dc/term"
   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.

My web server is (include version):

certbot --http-01-port=8888

The operating system my web server runs on is (include version):

4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 GNU/Linux

My hosting provider, if applicable, is:

self-hosted

I can login to a root shell on my machine (yes or no, or I don't know):

yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

certbot 0.31.0

I have investigated doing an upgrade, as suggested by the error message above, but this seems to be the latest version available in my packaging system.

2

Note that the above option does not make the Let's Encrypt validation server to try to connect to port 8888. This --http-01-port option only exists for certain fringe situations where, for example, a NAT router port maps the external port 80 to internal port 8888. Or perhaps a reverse proxy proxying certain requests on port 80 to http://localhost:8888.

So I'm interested to know how & why you're using the --http-01-port option to let certbot listen on port 8888?

Also:

Are these options really necessary? Also, these options should point to the files (i.e., private key file and fullchain file respectively), not to a directory. Isn't it much easier to just use --cert-name maafascreamsnews.com?

Don't use this option. It won't force Let's Encrypt to suddenly grant you a certificate if it doesn't really want to. It will only generate duplicates which are unnecessary, as that would indicate you already got a certificate in the first place.

That's just a warning and can be ignored, the error is further down the output.

In addition to the above: I'm curious where you got the options you've used from. Are you using some kind of guide? Or did you get these options from the certbot documentation?

1 Like
3

My script which is driving this, and which has evolved over time these last couple of years, but which was most recently updated three or four months ago, includes these comments:

# https://www.lab-time.it/2018/09/20/running-haproxy-and-lets-encrypt-on-docker/ 
# https://serversforhackers.com/c/letsencrypt-with-haproxy

I was able to use this script to successfully generate a certificate for another of my domains immediately before I encountered these errors on this domain.

I have a reverse proxy running at port 80, with this in the haproxy.cfg:

frontend http_proxy
  bind 172.17.0.8:80
  acl letsencrypt-acl path_beg -i /.well-known/acme-challenge/

  .  .  .  

  use_backend letsencrypt if letsencrypt-acl

  .  .  .  

backend letsencrypt
  mode http
  server letsencrypt_node_01 192.168.51.121:8888
  server letsencrypt_node_02 209.195.11.75:8888
  timeout connect 1h
  timeout server 1h

Examining this makes me wonder if perhaps only one of these addresses is actually listening to the certbot server, and the issue lies with haproxy routing traffic in a round-robin fashion to an IP where nothing is listening.

I have updated the haproxy.cfg and my certbot wrapping script to be explicit as to which IP it should bind.

     --http-01-address=192.168.51.121 \
     --http-01-port=8888

Testing again. But now encountering a **Planned Maintenance In Progress** message at: https://letsencrypt.status.io/

4

Maintenace seems to have ended :slight_smile:

Please consider dropping --force-renewal from your script: it serves no real purpose, except in fringe circumstances (such as adding must staple to a cert not already having it) and most of the time it only leads to unnecessary added load to the Let's Encrypt servers and may lead you to run into rate limits.

5

Thanks. Have run my test again. It appears my haproxy configuration is scrambled and that these requests are being high-jacked by the next best backend for serving them. Will investigate this as an haproxy issue, next:

Apr  5 17:14:06 127.0.0.1 haproxy[45188]: 3.128.26.105:42052 [05/Apr/2021:17:14:06.090] https_in~ www_maafascreamsnews_cluster/server_maafa_screams_news_www 0/0/1/58/59 404 8853 - - ---- 4/3/0/0/0 0/0 "GET /.well-known/acme-challenge/7zwvm7aW-TPPXHbtuzx7Ha9_QAl1qwBHmfGFer1x9Bc HTTP/1.1"
Apr  5 17:14:06 127.0.0.1 haproxy[45188]: 34.211.6.84:51004 [05/Apr/2021:17:14:06.149] http_proxy http_proxy/<NOSRV> 0/-1/-1/-1/0 301 187 - - LR-- 3/1/0/0/0 0/0 "GET /.well-known/acme-challenge/Bpq3Kjd0JaM5B0EG2N6Hv5HQl5JS8mDjBUURqo1t3CE HTTP/1.1"
Apr  5 17:14:06 127.0.0.1 haproxy[45188]: 3.128.26.105:42094 [05/Apr/2021:17:14:06.163] https_in~ www_maafascreamsnews_cluster/server_maafa_screams_news_www 0/0/1/32/33 404 8853 - - ---- 4/4/0/0/0 0/0 "GET /.well-known/acme-challenge/Bpq3Kjd0JaM5B0EG2N6Hv5HQl5JS8mDjBUURqo1t3CE HTTP/1.1"
Apr  5 17:14:06 127.0.0.1 haproxy[45188]: 34.211.6.84:60956 [05/Apr/2021:17:14:06.216] https_in~ www_maafascreamsnews_cluster/server_maafa_screams_news_www 0/0/1/6/7 404 8852 - - ---- 3/3/0/0/0 0/0 "GET /.well-known/acme-challenge/7zwvm7aW-TPPXHbtuzx7Ha9_QAl1qwBHmfGFer1x9Bc HTTP/1.1"
Apr  5 17:14:06 127.0.0.1 haproxy[45188]: 66.133.109.36:32840 [05/Apr/2021:17:14:06.232] https_in~ www_maafascreamsnews_cluster/server_maafa_screams_news_www 0/0/1/7/8 404 8852 - - ---- 2/2/0/0/0 0/0 "GET /.well-known/acme-challenge/Bpq3Kjd0JaM5B0EG2N6Hv5HQl5JS8mDjBUURqo1t3CE HTTP/1.1"
Apr  5 17:14:06 127.0.0.1 haproxy[45188]: 52.28.236.88:38542 [05/Apr/2021:17:14:06.248] http_proxy http_proxy/<NOSRV> 0/-1/-1/-1/0 301 187 - - LR-- 2/1/0/0/0 0/0 "GET /.well-known/acme-challenge/Bpq3Kjd0JaM5B0EG2N6Hv5HQl5JS8mDjBUURqo1t3CE HTTP/1.1"
Apr  5 17:14:06 127.0.0.1 haproxy[45188]: 66.133.109.36:16158 [05/Apr/2021:17:14:06.243] https_in~ www_maafascreamsnews_cluster/server_maafa_screams_news_www 0/0/1/7/8 404 8852 - - ---- 1/1/0/0/0 0/0 "GET /.well-known/acme-challenge/7zwvm7aW-TPPXHbtuzx7Ha9_QAl1qwBHmfGFer1x9Bc HTTP/1.1"

I also commented out that --force-renewal invocation.

This is looking relevant:

https://serverfault.com/posts/647487/revisions

I am seeking support on this question here: https://haproxy.slack.com/archives/C8EKNPFFH/p1617652234302500

1 Like
6

This was absolutely an haproxy issue.

Resolved by commenting out a line reading:

use_backend www_maafascreamsnews_cluster if { ssl_fc_sni_reg maafascreamsnews.com }
1 Like
7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.