Generate cert for Node apps through Nginx reverse proxy?

Server
1

I’m running several node apps proxyed through nginx (cloudflare is running DNS as well, the worst possible setup I know). I’ve tried multiple ways to authenticate with Let’s Encrypt and I keep running into errors. After reading through the various discussions I think I’m supposed to be using --webroot?

I run this: ./letsencrypt-auto certonly --webroot -w /path/to/node/app/ -d domain.net -d www.domain.net

and get this:

IMPORTANT NOTES:
 - The following 'urn:acme:error:connection' errors were reported by
   the server:

   Domains: www.domain.net
   Error: The server could not connect to the client to verify the
   domain
 - The following 'urn:acme:error:unauthorized' errors were reported by
   the server:

   Domains: domain.net
   Error: The client lacks sufficient authorization
2

It’ll be easier for us to help debug if you’re willing to list the actual domain name you’re using.

You’re correct that webroot is the best current option for Nginx users. The connection error could be a number of things. Can you run with -vvv and paste the full log?

Can you double-check that your site is publicly accessible from the Internet? On both the www and non-www versions?

3

Sorry, the domain is adamsimpson.net. The site is up and available. www currently 301 redirects to non-www via a server block like so:

server {
   server_name  www.adamsimpson.net;
   return 301 http://adamsimpson.net$request_uri;
 }

The -vvv output was really hard to parse, so here’s the -v output:

/etc/letsencrypt/keys/0018_key-letsencrypt.pem
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
http-01 challenge for adamsimpson.net
Waiting for verification...
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
errors were reported by the server:
Error: The client lacks sufficient authorization
Cleaning up challenges

followed by:

Failed authorization procedure. www.adamsimpson.net (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Error parsing key authorization file: Invalid key authorization: 30 parts, adamsimpson.net (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Error parsing key authorization file: Invalid key authorization: 30 parts

IMPORTANT NOTES:
 - The following 'urn:acme:error:unauthorized' errors were reported by
   the server:

   Domains: adamsimpson.net, www.adamsimpson.net
   Error: The client lacks sufficient authorization

Hope that helps shine a light on what’s going wrong on my end.

4

I wrote up this guide for CentOS 7 with nginx.

5

I had a similar situation and problem. I prevented the redirection for the .well-known directory and it then succeeded.

server {
    server_name www.example.com;
     location /.well-known {
        root /wherever/your/root/is;
    }
    location / {
        return 301 http://example.com$request_uri;
    }
}

From reading other posts it seems like it should follow redirection so I would welcome clarification from someone that knows. It could be that the real problem was something else.

6

I got my certs! Thanks for the suggestions everyone.

Here’s what I ended up having to do:

  • for both root and www domains add this to my nginx vhost:
location /.well-known {
  root /wherever/your/root/is;
}
  • Cloudflare wasn’t a problem at all.
  • Seems like the client should be able to follow a reverse proxy / 301 redirect without having to explicitly add a rule for it?

So to recap, for a node app behind a nginx reverse proxy: add a specific location entry in your vhost for both root and www.

7

I’ve done the same with my server blocks (though I use a single common root for LE rather than letting it go into each application’s webroot) since the public beta launched, and have been able to issue (and renew, for that matter) 2 certificates covering 3 domains.

That said, though, during the earlier closed beta, I successfully issued a certificate for both www and non-www even though the former used a 301 redirect to the latter (didn’t even occur to me to consider that until after it worked), so I don’t think the redirect itself should be the problem unless the server side has been changed since then to reject redirects; there was even a thread concerning this very topic and suggesting the server not follow redirects, though IIRC we had an LE engineer or two chime in saying that this was intended and desired behavior and wouldn’t be changing.