[resolved] Unauthorized Even Using Staging

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. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

I tried gitlab.ciwise.com for several times and couldn’t get NGINX to listen on 443. I realized there are rate limits so I deleted my DNS gitlab.ciwise.com and switched to devops.ciwise.com. I then added --staging and still get unauthorized. Not sure where to go from here.

My domain is: devops.ciwise.com

I ran this command: certbot certonly --staging --webroot --webroot-path=/var/www/letsencrypt -d devops.ciwise.com

It produced this output:
(A)gree/©ancel: A
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for devops.ciwise.com
Using the webroot path /var/www/letsencrypt for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. devops.ciwise.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://devops.ciwise.com/.well-known/acme-challenge/0MmRAhENzB-tJ67lqoElNanLivk397jkSkq55feaZW0: "

<meta content="IE"

IMPORTANT NOTES:

  • If you lose your account credentials, you can recover through
    e-mails sent to david@ciwise.com.

  • The following errors were reported by the server:

    Domain: devops.ciwise.com
    Type: unauthorized
    Detail: Invalid response from
    http://devops.ciwise.com/.well-known/acme-challenge/0MmRAhENzB-tJ67lqoElNanLivk397jkSkq55feaZW0:
    "

    <meta content="IE"

    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.

  • Your account credentials have been saved in your Certbot
    configuration directory at /etc/letsencrypt. You should make a
    secure backup of this folder now. This configuration directory will
    also contain certificates and private keys obtained by Certbot so
    making regular backups of this folder is ideal.

My web server is (include version): Gitlab (NGINX embedded)

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

My hosting provider, if applicable, is: DigitalOcean

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):

#2

The nginx location rule you presumably added to map https://devops.ciwise.com/.well-known/acme-challenge/ to /var/www/letsencrypt doesn’t appear to be working. A common mistake is to include .well-known/acme-challenge in the root argument while actually nginx appends that.

If you could share the bit of nginx config you added to enable webroot authentication out of /var/www/letsencrypt we might be able to see what’s wrong with it. Or if you didn’t add any nginx configuration, you probably just want to use the public directory of your gitlab installation as your webroot instead.

#3

The complaint is pretty straight forward:

In review of that URL and site, it seems to only return 10699 byte html login page file that’s titled:
<title>Sign in · GitLab</title>

#4

I did use “root” in the config (attached) but since I’m trying to get the cert to work, I commented out this and gitlab (NGINX) is running using HTTP only now and when I ran the command that was unauthorized.

   # nginx['custom_gitlab_server_config']="location ^~ /.well-known { root /var/www/letsencrypt; }"
   # nginx['redirect_http_to_https'] = true
   # nginx['ssl_certificate'] = "/etc/letsencrypt/live/devops.ciwise.com/fullchain.pem"
   # nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/devops.ciwise.com/privkey.pem"

So not sure since it’s commented. When I tried to get the cert to work and changed my DNS from gitlab.ciwise.com to devops.ciwise.com, I do remove everything from /etc/letsencrypt but /var/www/letsencrypt/.well-known is still there and empty.

David

#5

Should I run the cert creation with Gitlab shut down. I’m assuming that certbot automatically sets up a listener on HTTPS I thought, but I notice it’s HTTP (80) when it tries the acme site even using --staging.

I’m not sure how to do this because it’s Gitlab (A ruby on rails app using NGINX that’s part of the install package). I followed other how-to pages and the instructions were all similar. My issue is that even when I created a cert and configured, the connection after HTTP to HTTPS redirect occurred was forbidden.

This posting for help is because now I can’t seem to create the cert again.

David

#6

You will need to uncomment this line to achieve validation and obtain a certificate.

#7

LOL. I just added .well-known/acme-challenge and uncommented. It worked. The issue is that these how-tos on the web are written sometimes with no explanation of why. I realized that even though my Gitlab was running on port 80, this webroot needed to be in place when I run certbot.

Thanks for your help. Now, I have to get NGINX to host the certificate now. I think it may be permissions or owner issues. I’ll get it I’m sure.

Thanks again.

David

1 Like
#8

Just tried again and ERR_CONNECTION_REFUSED

NGINX is doing the redirect because my browser address switched to https://…

I’m hoping it’s just permissions now.

David

#9

If you run ss -tl on the server is there an https listing?

Are there any messages in your nginx’s error.log file?

#10

LISTEN 0 511 *:https :

Looking for the NGINX log now

#11

2017/10/04 23:06:43 [emerg] 7118#0: BIO_new_file("/etc/letsencrypt/live/gitlab.ciwise.com/fullchain.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen(’/etc/letsencrypt/live/gitlab.ciwise.com/fullchain.pem’,‘r’) error:2006D080:BIO routines:BIO_new_file:no such file)

Last entry. This was last night before I changed the DNS thinking I used all my certs for the week. So I guess it means nothing because I don’t know if NGINX is doing the HTTPS challenge. I only know that http url redirects to https. I also have flushed iptables and setup http and https ACCEPT. And, above the ss command says I’m listening on 443. I’m going to telnet devops.ciwise.com 443 now to check external.

#12

Blocked or either NGINX isn’t really hosting the certificate yet.

Connection to devops.ciwise.com closed.
[~]$ telnet devops.ciwise.com 443
Trying 107.170.14.62…
telnet: connect to address 107.170.14.62: Connection refused
telnet: Unable to connect to remote host
[~]$

#13

com
devops.ciwise.com.png958×602 46.4 KB

Thanks everyone for the help.

1 Like
#14

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