Failed certifying - Unauthorized: HELP!

I am in the mist of setting up a Zencash secure node on Ubuntu 18 that I have set up in Hyper-V. I am having issues with getting the certificate installed to it.
I've been following the Secure & Super Nodes guide on to configure this and at this point I have reached a road block at Part 6 due to my novice on this TLS certification stuff. Could someone please help guide me to the right direction to get past this stop. Thanks!

The command entered:

sudo certbot certonly -n --agree-tos --register-unsafely-without-email --standalone -d $FQDN\

outputs the following:

zennode@Linux-CVM1:/home/testminer$ sudo certbot certonly -n
--agree-tos --register-unsafely-without-email --standalone -d $FQDN
[sudo] password for zennode:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. (http-01):
urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient
authorization :: Invalid response from
q%!(EXTRA string=
)HTML>Not Found


I am very green in this area and not quite sure how this certificate is suppose to get issued. The first time I ran the command above, I was using an internal FQDN which I know now is not allowed. Since I understand that this request requires a external FQDN be used I think I am able to accommodate the request since I have a registered domain I use for web hosting on my Win 2008 Server I have in Hyper-V.

I am unsure if my Ubuntu system also on Hyper-V (on a different system on the network) issuing the cert request if the Zen dameon need to be on my web server. From the error, is it trying to write something to a path from the FQDN I created. Do I need to setup something on IIS on that web server so it can listen for issuing cert?

I drew up a rudimentary topology graph to help give an idea of how my home network setup as I know it is currently functioning.

Pretty much, yes. The CA will make a request to a path on your FQDN to confirm that you control the domain; your ACME client (in this case certbot) needs to be able to respond to that challenge. You are using standalone mode which means certbot will start up its own temporary web server on the Ubuntu VM, but that will never receive the request from the CA because your router is sending it to the Win 2008 server instead. So for example you could temporarily configure the router to send port 80 traffic to the Ubuntu VM, or you could configure IIS to proxy everything under /.well-known/acme-challenge/ to the Ubuntu VM, or you could forget about certbot and choose a Windows-compatible ACME client to run on the Win 2008 server VM instead.

I have no experience with IIS so if you need more detail someone else will have to jump in, sorry :slight_smile:

or you could configure IIS to proxy everything under /.well-known/acme-challenge/ to the Ubuntu VM,

I like this suggestion. I will see if I can try this out. Thanks.

Also, you can use DNS validation, if it’s feasible with your DNS provider and ACME client. (There are packages available for Certbot and a number of popular DNS providers for Ubuntu 18.04.) Then you wouldn’t have to deal with HTTP at all.

1 Like
  • Okay, I have IIS server properly URL redirecting traffic outside of path to my internal Ubuntu VM. (I followed the reverse-proxy config suggested here )

  • With SimpleHTTPServer set to 8008 (sudo python -m SimpleHTTPServer 8008) the Ubuntu server is listening to that port that I specified in my reverse proxy configuration to redirect communication over to.

  • Ubuntu firewall disabled (sudo ufw disable) so I could set other ports for SimpleHTTPServer to listen to besides port 80 (which will conflict with cerbot if not changed).

  • text/plain MIME setting set in IIS to read so extensionless files like the configcheck file.

But after all that he certbot still gives the unauthorized error. I’m beginning to wonder if this is a write permissions issue?

  • What authentication method is cerbot using with this http-01 challenge that it’s failing at, and do I need to have some preset configured for it to accomplish this as I am assuming that’s what it means by not authorized.

If you're still using the same certbot command that you started with, certbot will start its own temporary HTTP server when you run it - you don't need a separate one. That temporary server should respond to the challenge from the CA, but it can't do that if you're sending the challenge to SimpleHTTPServer on port 8008 instead :wink:

You can configure IIS to proxy to port 80 which is where certbot will listen by default. Or if you want to keep your existing proxy configuration you can tell certbot to listen on a different port with the --http-01-port option. Or if you want to use SimpleHTTPServer, you could use --webroot -w /path/to/directory instead of --standalone, where /path/to/directory is the place that SimpleHTTPServer serves files from (assuming it does that, I'm not familiar with it).

The reason I launched SimpleHTTPServer and set it to port 8008 was because without it.
The reverse proxy set in IIS would throw a Server Error 502 if I attempted to access my FQDN specified in the certbot command.

Check it out 502 error.

I realized it was throwing that error because the reverse proxy set under URL Rewrite in IIS was configured to Rewrite URL to which is the Unbuntu VM, but it appeared Ubuntu was not listening to that port at all. Hence 502 error if you try to access my FQDN set up for it.

The only way I could confirm that the reverse proxy was working was by manually setting up a web server with SimpleHTTPServer to listen to 80, and then change it to port 8008 since certbot was trying to establish its own web server on 80. I figured certbot was doing that merely be able to send out it’s verfication. So when SimpleHTTPServer 8008 is running, accessing my FQDN will show the directory listing of my Linux Home directory. << Is this NOT supposed to be the effect of the Reverse Proxy solution?

Would certbot if it hypothetically worked, opening up port 80 in ubuntu to receive traffic sent from IIS, then is there another way to test the configuration. I figured SimpleHTTPServer was a good way to test, but if that URL Rewrite needs to go to the port certbot listens to then it just breaks the Reverse proxy and throws a 502 error like it’s doing right now.

If certbot is opening a temporary HTTP server at port 80, is it automatically trying to send a CA challenge to itself (from the IIS redirect to right back to itself on ubuntu)??? or is the CA challenge coming from a centralized host on the web?

I’m trying to get this to work but also better understand what is this process actually trying to do.

The challenge is a HTTP request that comes in from a server on the web that is operated by Let’s Encrypt. Certbot (when you use --standalone) tries to listen on port 80 so that it can receive that request and respond to it.

I suspect you maybe just configured IIS to proxy too much. You only need to send paths beginning with /.well-known/acme-challenge/ to certbot. Those paths will still give you a 502 error while certbot isn’t running, but that shouldn’t be a problem.

Does this process suppose to happen instantaneously at the first try?

Will it write a certification file to that path? which in my case would be at the physical location of c:\inetpub\zen.well-known\acme-challenge ?

I don’t think this reverse proxy is going to work as intended for this process I’m following because my next steps are to copy that root CA and that’s going to be next to impossible to do out of ubuntu if the root CA is stored on the directories the IIS is on.

See this here the extensionless file was put there by Certify that certified that FQDN I set up so it would show secured HTTPS, but I don’t think this was even necessary since certbot shows that it’s using just http, but those linked suggestions for acme-challenge in IIS seem to reference the need of HTTPS. Did my FQDN need to be CA before hand, only for letsencrypt to do it’s own CA certification? It feels redundant in addition to not working.

Hmm. I'm not sure I understand what you're trying to achieve. You've got a valid certificate and working HTTPS on your IIS server, and your router is sending your incoming HTTPS traffic there. Do you intend to run zencash on a different port? You won't be able to use https://fqdn because that's port 443, which goes to IIS. You could, of course, configure IIS to proxy that traffic to zencash, which is what the tutorial you linked assumes you want. In that case you don't really need a certificate on the Ubuntu server at all (assuming your local network is sufficiently secure).

If you want zencash doing its own HTTPS on a different port, you will want to proxy the ACME challenge URLs to certbot, which is the opposite of what the tutorial does - it excludes them (so that Certify can work) and proxies everything else.

No, it will write the certificate and related files to /etc/letsencrypt/archive/yourdomainname on the Ubuntu box, and create symbolic links in /etc/letsencrypt/live/yourdomainname.

No. Let's Encrypt will make a HTTP request to your server on port 80. If you can respond correctly on port 80, you can get a certificate. If you redirect to HTTPS and you can respond correctly on port 443, that also works, whether your existing certificate is publicly trusted or not, but that's in no way necessary.

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