Certonly - regular VS staging -?

Help
1

Hi guys.

Still newbie so go easy on me - I find this weird:

-> $ certbot-apps certonly -v --agree-tos --domain some.xyz --webroot --webroot-path /apps/www/certbot --email webadm@some.xyz --staging

that works, certs are downloaded. But the same - regular, no staging - fails:

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
  Domain: some.xyz
  Type:   unauthorized
  Detail: SOME.IP: Invalid response from http://some.xyz/.well-known/acme-challenge/xv52V43h1P9Zk6VpnwsbRwyqM: 404

With Nginx as here:

server {
listen :80;
server_name some.xyz;
location /.well-known/acme-challenge {
alias /apps/www/certbot;
}
location / {
return 301 https://$host$request_uri;
}
#error_log /var/log/nginx/debug.log debug;
}

Some bits are redacted as you can see.

Could you explain what makes one work and another fail?
And why 'regular' one fail?

many thanks, L.

2

that's likely be your / your isp's firewall setting so not much thing can say about without your domain

4 Likes
3

What does certbot-apps do? Anything more than just invoking certbot ?

3 Likes
5

Nothing apart from being an alias with paths specified.

6

Probably a cached validation on the staging server being reused, so successful issuance without trying a new validation attempt whereas there actually is an issue currently.

You could try --dry-run instead of --staging to see what happens. --dry-run also makes use of the staging environment, but disables cached validations first before attempting to get a certificate, thus triggering a validation attempt every time.

If --dry-run fails, then you know something has happened between a previous succesful validation and the current situation. If --dry-run succeeds but an attempt on the production environment doesn't, then something strange is going on.

5 Likes
7

I think it has something to do with Nginx config

If 'location /.well-known/acme-challenge' part is absent but ' location /' is present then all 'versions' fail with:

  Type:   unauthorized
  Detail: SOME.IP: Invalid response from https://duckduckgo.com: "<!DOCTYPE html>\n<!--[if IEMobile 7 ]> <html lang=\"en-US\" class=\"no-js iem7\"> <![endif]-->\n<!--[if lt IE 7]> <html class=\"ie6 lt-"

Which 'duckduckgo' would be a redirection from one of the other virtual hosts - which one? I don't how Nginx decides to which it "fails-over", but!...
...question in such case I want to ask is - why LetsEncrypt would bother with '/' or anything other than '/.well-known/acme-challenge' ? and if that what has to happen for Letsencrypt works this way then..
...is it possible to have a 'server' - with Nginx - to work with certbot 'auto-updates' and redirect HTTP do HTTPS (for everything other LetsEncrypt)?

thanks, L.

8

Let's Encrypt doesn't "bother", it just requests a certain path (starting with /.well-known/acme-challenge/ on a certain FQDN and it follows any redirect it receives. It's up to the webserver to either serve the challenge token or provide a correct redirect to that challenge token.

Often webservers are mis-configured, however, without the actual FQDN we can't test that remotely. Note that providing the exact domain name is mandatory to actually get help on the Community, as shown by the questionnaire which should have been provided to you when you opened this thread in the Help section:

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:

I ran this command:

It produced this output:

My web server is (include version):

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

My hosting provider, if applicable, is:

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

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

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

4 Likes
9

But it does not seem (to me) that LetsEncrypt start with /.well-known/acme-challenge/ like you say, for if this is present:

location / {
return 301 https://$host$request_uri;
}

then I always get LetsEncrypt go there - to duckduckgo in my case - redirected via another virtual host.
If '/' location is absent and whole config looks just like:

server {
listen :80;
server_name some.xyz;
root /apps/www/certbot;
location /.well-known/acme-challenge {
alias /apps/www/certbot;
}

then it fails:

  Type:   unauthorized
  Detail: SOME.IP: Invalid response from http://some.xyz/.well-known/acme-challenge/Pg4ObshVAqMGRQPuAMF9MOnHafmeKe-Wt28Ct8yaR90: 404

but if no location is used and config is just like:

server {
listen :80;
server_name some.xyz;
root /apps/www/certbot;
}

then all works, certs are obtained.

I think it's rather general/generic "issue" than something specific to my domain.

certbot 1.22.0
nginx/1.14.1
on CentOS 8 Stream

My goal is rather obvious here - I'd believe many want to have or already have it work like so: all HTTP is redirected to HTTPs except for LetsEncrypt's bit - naturally.

many thanks, L.

10

ping some.xyz
ping: some.xyz: Name or service not known

Also some.xyz does not seem to have any DNS records

1 Like
11

I wrote in my first message - Some bits are redacted as you can see - in other words, obfuscated.

12

As @Osiris said there FQDN is needed to remotely check what is happening, we are trying to figure out why your site configuration isn't working with Let's Encrypt. Obviously you have to supply the FQDN to your ACME agent to get any certificate from Let's Encrypt.

Thank you for assisting us in helping YOU!

1 Like
13

Let's Encrypt supplies certificates to domains for domain verification, obfuscation is difficult to do domain verification on.

1 Like
14

I think you need to change alias to root like:

location /.well-known/acme-challenge {
root /apps/www/certbot;
}
3 Likes
15

That's just the http-01 challenge of the ACME protocol. Please see RFC 8555 for more details about the ACME protocol, but rest assured, the http-01 challenge will request a path starting with /.well-known/acme-challenge/. What happens next is NOT due to Let's Encrypt, but due to webserver (mis)configuration.

5 Likes
16

! bull's-eye !
working simple config is:

server {
listen :80;
server_name some.xyz;
root /apps/www/certbot;
location / {
return 301 https://$host$request_uri;
}
location /.well-known/acme-challenge {
root /apps/www/certbot;
}
}

and '--dry-run' might have helped too.
many ! thanks, L

2 Likes
17

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