Bitten by 403 Forbidden on .well-known/acme-challenge

Help
1

I've used acme.sh on another server and it was very easy to set up. On this server, however, I've run into 403 errors, and despite hours of struggling, haven't been able to figure it out. The crucial line in the output below is sfbiochar.com:Verify error:Invalid response from http://sfbiochar.com/.well-known/acme-challenge/-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk [139.162.183.20]

I've deleted the /var/www/html directory I set up yesterday after hours of attempts to resolve this, recreated it, set permissions for 775 access, ran the command again, and the file referenced above is there.

Here is the nginx config snippet as it currently stands. I've tried dozens of variations.

location ^~ /.well-known {
allow all;
alias /var/www/html/.well-known/;
default_type "text/plain";
try_files $uri =404;
}
location ^~ /.well-known/acme-challenge/ {
allow all;
root /var/www/html;
}

I can't seem to get the nginx config correct. I've created test files yesterday and tried to access them, no joy. So of course
curl http://sfbiochar.com/.well-known/acme-challenge/-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk
returns a 403

Any help would be greatly appreciated.

My domain is: sfbiochar.com

I ran this command: acme.sh --staging --issue -d sfbiochar.com -w /var/www/html --debug

It produced this output:
[Wed Oct 21 09:12:51 UTC 2020] Lets find script dir.

[Wed Oct 21 09:12:51 UTC 2020] SCRIPT='/root/.acme.sh/acme.sh'

[Wed Oct 21 09:12:51 UTC 2020] _script='/root/.acme.sh/acme.sh'

[Wed Oct 21 09:12:51 UTC 2020] _script_home='/root/.acme.sh'

[Wed Oct 21 09:12:51 UTC 2020] Using config home:/root/.acme.sh

v2.8.8

[Wed Oct 21 09:12:51 UTC 2020] Running cmd: issue

[Wed Oct 21 09:12:51 UTC 2020] _main_domain='sfbiochar.com'

[Wed Oct 21 09:12:51 UTC 2020] _alt_domains='no'

[Wed Oct 21 09:12:51 UTC 2020] Using config home:/root/.acme.sh

[Wed Oct 21 09:12:51 UTC 2020] Using ACME_DIRECTORY: https://acme-staging-v02.api.letsencrypt.org/directory

[Wed Oct 21 09:12:51 UTC 2020] ACME_DIRECTORY='https://acme-staging-v02.api.letsencrypt.org/directory'

[Wed Oct 21 09:12:51 UTC 2020] DOMAIN_PATH='/root/.acme.sh/sfbiochar.com'

[Wed Oct 21 09:12:51 UTC 2020] Using ACME_DIRECTORY: https://acme-staging-v02.api.letsencrypt.org/directory

[Wed Oct 21 09:12:51 UTC 2020] _init api for server: https://acme-staging-v02.api.letsencrypt.org/directory

[Wed Oct 21 09:12:51 UTC 2020] GET

[Wed Oct 21 09:12:51 UTC 2020] url='https://acme-staging-v02.api.letsencrypt.org/directory'

[Wed Oct 21 09:12:51 UTC 2020] timeout=

[Wed Oct 21 09:12:51 UTC 2020] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header -g '

[Wed Oct 21 09:12:52 UTC 2020] ret='0'

[Wed Oct 21 09:12:52 UTC 2020] ACME_KEY_CHANGE='https://acme-staging-v02.api.letsencrypt.org/acme/key-change'

[Wed Oct 21 09:12:52 UTC 2020] ACME_NEW_AUTHZ

[Wed Oct 21 09:12:52 UTC 2020] ACME_NEW_ORDER='https://acme-staging-v02.api.letsencrypt.org/acme/new-order'

[Wed Oct 21 09:12:52 UTC 2020] ACME_NEW_ACCOUNT='https://acme-staging-v02.api.letsencrypt.org/acme/new-acct'

[Wed Oct 21 09:12:52 UTC 2020] ACME_REVOKE_CERT='https://acme-staging-v02.api.letsencrypt.org/acme/revoke-cert'

[Wed Oct 21 09:12:52 UTC 2020] ACME_AGREEMENT='https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf'

[Wed Oct 21 09:12:52 UTC 2020] ACME_NEW_NONCE='https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce'

[Wed Oct 21 09:12:52 UTC 2020] ACME_VERSION='2'

[Wed Oct 21 09:12:52 UTC 2020] Le_NextRenewTime

[Wed Oct 21 09:12:52 UTC 2020] Using CA: https://acme-staging-v02.api.letsencrypt.org/directory

[Wed Oct 21 09:12:52 UTC 2020] _on_before_issue

[Wed Oct 21 09:12:52 UTC 2020] _chk_main_domain='sfbiochar.com'

[Wed Oct 21 09:12:52 UTC 2020] _chk_alt_domains

[Wed Oct 21 09:12:52 UTC 2020] Le_LocalAddress

[Wed Oct 21 09:12:52 UTC 2020] d='sfbiochar.com'

[Wed Oct 21 09:12:52 UTC 2020] Check for domain='sfbiochar.com'

[Wed Oct 21 09:12:52 UTC 2020] _currentRoot='/var/www/html'

[Wed Oct 21 09:12:52 UTC 2020] d

[Wed Oct 21 09:12:52 UTC 2020] _saved_account_key_hash is not changed, skip register account.

[Wed Oct 21 09:12:52 UTC 2020] Read key length:

[Wed Oct 21 09:12:52 UTC 2020] _createcsr

[Wed Oct 21 09:12:52 UTC 2020] Single domain='sfbiochar.com'

[Wed Oct 21 09:12:52 UTC 2020] Getting domain auth token for each domain

[Wed Oct 21 09:12:52 UTC 2020] d

[Wed Oct 21 09:12:52 UTC 2020] url='https://acme-staging-v02.api.letsencrypt.org/acme/new-order'

[Wed Oct 21 09:12:52 UTC 2020] payload='{"identifiers": [{"type":"dns","value":"sfbiochar.com"}]}'

[Wed Oct 21 09:12:52 UTC 2020] RSA key

[Wed Oct 21 09:12:52 UTC 2020] HEAD

[Wed Oct 21 09:12:52 UTC 2020] _post_url='https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce'

[Wed Oct 21 09:12:52 UTC 2020] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header -g -I '

[Wed Oct 21 09:12:53 UTC 2020] _ret='0'

[Wed Oct 21 09:12:53 UTC 2020] POST

[Wed Oct 21 09:12:53 UTC 2020] _post_url='https://acme-staging-v02.api.letsencrypt.org/acme/new-order'

[Wed Oct 21 09:12:53 UTC 2020] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header -g '

[Wed Oct 21 09:12:54 UTC 2020] _ret='0'

[Wed Oct 21 09:12:54 UTC 2020] code='201'

[Wed Oct 21 09:12:54 UTC 2020] Le_LinkOrder='https://acme-staging-v02.api.letsencrypt.org/acme/order/16213527/170444065'

[Wed Oct 21 09:12:54 UTC 2020] Le_OrderFinalize='https://acme-staging-v02.api.letsencrypt.org/acme/finalize/16213527/170444065'

[Wed Oct 21 09:12:54 UTC 2020] url='https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/137152656'

[Wed Oct 21 09:12:54 UTC 2020] payload

[Wed Oct 21 09:12:54 UTC 2020] POST

[Wed Oct 21 09:12:54 UTC 2020] _post_url='https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/137152656'

[Wed Oct 21 09:12:54 UTC 2020] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header -g '

[Wed Oct 21 09:12:54 UTC 2020] _ret='0'

[Wed Oct 21 09:12:54 UTC 2020] code='200'

[Wed Oct 21 09:12:55 UTC 2020] d='sfbiochar.com'

[Wed Oct 21 09:12:55 UTC 2020] Getting webroot for domain='sfbiochar.com'

[Wed Oct 21 09:12:55 UTC 2020] _w='/var/www/html'

[Wed Oct 21 09:12:55 UTC 2020] _currentRoot='/var/www/html'

[Wed Oct 21 09:12:55 UTC 2020] entry='"type":"http-01","status":"pending","url":"https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/137152656/DPDNQA","token":"-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk"'

[Wed Oct 21 09:12:55 UTC 2020] token='-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk'

[Wed Oct 21 09:12:55 UTC 2020] uri='https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/137152656/DPDNQA'

[Wed Oct 21 09:12:55 UTC 2020] keyauthorization='-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk.Rj3xNldqNb7joV9uB8cA4O12fBfbmSEYIo3CVKZ3Hr8'

[Wed Oct 21 09:12:55 UTC 2020] dvlist='sfbiochar.com#-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk.Rj3xNldqNb7joV9uB8cA4O12fBfbmSEYIo3CVKZ3Hr8#https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/137152656/DPDNQA#http-01#/var/www/html'

[Wed Oct 21 09:12:55 UTC 2020] d

[Wed Oct 21 09:12:55 UTC 2020] vlist='sfbiochar.com#-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk.Rj3xNldqNb7joV9uB8cA4O12fBfbmSEYIo3CVKZ3Hr8#https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/137152656/DPDNQA#http-01#/var/www/html,'

[Wed Oct 21 09:12:55 UTC 2020] d='sfbiochar.com'

[Wed Oct 21 09:12:55 UTC 2020] ok, let's start to verify

[Wed Oct 21 09:12:55 UTC 2020] Verifying: sfbiochar.com

[Wed Oct 21 09:12:55 UTC 2020] d='sfbiochar.com'

[Wed Oct 21 09:12:55 UTC 2020] keyauthorization='-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk.Rj3xNldqNb7joV9uB8cA4O12fBfbmSEYIo3CVKZ3Hr8'

[Wed Oct 21 09:12:55 UTC 2020] uri='https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/137152656/DPDNQA'

[Wed Oct 21 09:12:55 UTC 2020] _currentRoot='/var/www/html'

[Wed Oct 21 09:12:55 UTC 2020] wellknown_path='/var/www/html/.well-known/acme-challenge'

[Wed Oct 21 09:12:55 UTC 2020] writing token:-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk to /var/www/html/.well-known/acme-challenge/-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk

[Wed Oct 21 09:12:55 UTC 2020] Changing owner/group of .well-known to deva:webring

[Wed Oct 21 09:12:55 UTC 2020] url='https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/137152656/DPDNQA'

[Wed Oct 21 09:12:55 UTC 2020] payload='{}'

[Wed Oct 21 09:12:55 UTC 2020] POST

[Wed Oct 21 09:12:55 UTC 2020] _post_url='https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/137152656/DPDNQA'

[Wed Oct 21 09:12:55 UTC 2020] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header -g '

[Wed Oct 21 09:12:55 UTC 2020] _ret='0'

[Wed Oct 21 09:12:55 UTC 2020] code='200'

[Wed Oct 21 09:12:55 UTC 2020] trigger validation code: 200

[Wed Oct 21 09:12:55 UTC 2020] sleep 2 secs to verify

[Wed Oct 21 09:12:57 UTC 2020] checking

[Wed Oct 21 09:12:57 UTC 2020] url='https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/137152656/DPDNQA'

[Wed Oct 21 09:12:57 UTC 2020] payload

[Wed Oct 21 09:12:57 UTC 2020] POST

[Wed Oct 21 09:12:57 UTC 2020] _post_url='https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/137152656/DPDNQA'

[Wed Oct 21 09:12:57 UTC 2020] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header -g '

[Wed Oct 21 09:12:58 UTC 2020] _ret='0'

[Wed Oct 21 09:12:58 UTC 2020] code='200'

[Wed Oct 21 09:12:58 UTC 2020] sfbiochar.com:Verify error:Invalid response from http://sfbiochar.com/.well-known/acme-challenge/-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk [139.162.183.20]:

[Wed Oct 21 09:12:58 UTC 2020] Debug: get token url.

[Wed Oct 21 09:12:58 UTC 2020] GET

[Wed Oct 21 09:12:58 UTC 2020] url='http://sfbiochar.com/.well-known/acme-challenge/-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk'

[Wed Oct 21 09:12:58 UTC 2020] timeout=1

[Wed Oct 21 09:12:58 UTC 2020] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header -g --connect-timeout 1'

403 Forbidden

403 Forbidden

nginx/1.16.1

[Wed Oct 21 09:12:58 UTC 2020] ret='0'

[Wed Oct 21 09:12:58 UTC 2020] Debugging, skip removing: /var/www/html/.well-known/acme-challenge/-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk

[Wed Oct 21 09:12:58 UTC 2020] pid

[Wed Oct 21 09:12:58 UTC 2020] No need to restore nginx, skip.

[Wed Oct 21 09:12:58 UTC 2020] _clearupdns

[Wed Oct 21 09:12:58 UTC 2020] dns_entries

[Wed Oct 21 09:12:58 UTC 2020] skip dns.

[Wed Oct 21 09:12:58 UTC 2020] _on_issue_err

[Wed Oct 21 09:12:58 UTC 2020] Please add '--debug' or '--log' to check more details.

[Wed Oct 21 09:12:58 UTC 2020] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh

[Wed Oct 21 09:12:58 UTC 2020] url='https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/137152656/DPDNQA'

[Wed Oct 21 09:12:58 UTC 2020] payload='{}'

[Wed Oct 21 09:12:58 UTC 2020] POST

[Wed Oct 21 09:12:58 UTC 2020] _post_url='https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/137152656/DPDNQA'

[Wed Oct 21 09:12:58 UTC 2020] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header -g '

[Wed Oct 21 09:12:59 UTC 2020] _ret='0'

[Wed Oct 21 09:12:59 UTC 2020] code='400'

[Wed Oct 21 09:12:59 UTC 2020] socat doesn't exist.

[Wed Oct 21 09:12:59 UTC 2020] Diagnosis versions:

openssl:openssl

OpenSSL 1.0.2k-fips 26 Jan 2017

apache:

apache doesn't exist.

nginx:

nginx version: nginx/1.16.1

built by gcc 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC)

built with OpenSSL 1.0.2k-fips 26 Jan 2017

TLS SNI support enabled

configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/run/nginx.pid --lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx --with-file-aio --with-ipv6 --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-stream_ssl_preread_module --with-http_addition_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_slice_module --with-http_stub_status_module --with-http_perl_module=dynamic --with-http_auth_request_module --with-mail=dynamic --with-mail_ssl_module --with-pcre --with-pcre-jit --with-stream=dynamic --with-stream_ssl_module --with-google_perftools_module --with-debug --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic' --with-ld-opt='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,-E'

socat:
My web server is (include version): nginx/1.16.1

The operating system my web server runs on is (include version): CentOS Linux release 7.8.2003 (Core)

My hosting provider, if applicable, is: none

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): acme.sh v2.8.8

2

It seems like your webroot configuration is probably correct.

The 403 is suspicious because it's only showing up when the challenge file actually exists. That makes me think it's a permissions issue rather than a misconfiguration.

Does anything show up in nginx's error.log when those 403s occur?

Could you create this file so we can try request it manually?

echo "-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk" > "/var/www/html/.well-known/acme-challenge/-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk"
3

Ok, ran the echo command, even tho the file was present. Here are the permissions on that file with user and group anonymized:
acme-challenge]# ls -l
total 12
-rw-r--r--. 1 user group 44 Oct 21 10:52 -o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk

Same user and group that is used for the site files. I've just confirmed it to make sure. Still getting the 403 error.

4

Does anything show up at all in nginx's error.log when hitting sfbiochar.com/.well-known/acme-challenge/-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk?

nginx is definitely pointing to the right directory (because it only produces 403 for files that exist), so it really does have to be permissions or SELinux labels or whatever. I can't really think of any nginx directives that could cause this.

1 Like
5

I will look. Haven't done that yet.

6

2020/10/21 11:18:09 [error] 29679#0: *7445 open() "/var/www/html/.well-known/acme-challenge/-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk" failed (13: Permission denied), client: 17.58.85.87, server: sfbiochar.com, request: "GET /.well-known/acme-challenge/-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk HTTP/1.1", host: "sfbiochar.com"

Nothing very informative in the error log, it seems. (Except that some folks here are enjoying hitting that URL :smile: )

7

So it seems to be a permissions issue that I don't know how to resolve yet.

8

It's telling you that your nginx workers aren't running as a user which has sufficient permissions to open that file.

  1. Check what user is set to in nginx.conf.

  2. Check:

    sudo -u THE_USER namei -l "/var/www/html/.well-known/acme-challenge/-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk"

If that all checks out without an error, then try check also dmesg -w for denials (if e.g. SELinux or similar is running).

1 Like
9

Reading through https://www.ionos.com/community/server-cloud-infrastructure/nginx/solve-an-nginx-403-forbidden-error/ , I've reset the user and group on this directory to nginx.nginx, which is I believe the user running nginx. Running your -u command, I get the following output

drwxrwsr-x nginx nginx html
drwxr-sr-x nginx nginx .well-known
drwxr-sr-x nginx nginx acme-challenge
-rw-r--r-- nginx nginx -o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk

Still getting the 403.

dmesg -w outputs a long series of lines, but I don't see anything in it that looks like a denial.

10

Confirmed a second time that nginx is the user in nginx.conf:

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

Load dynamic modules. See /usr/share/nginx/README.dynamic.

include /usr/share/nginx/modules/*.conf;

events {
worker_connections 1024;
}

http {
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';

access_log  /var/log/nginx/access.log  main;

sendfile            on;
tcp_nopush          on;
tcp_nodelay         on;
keepalive_timeout   65;
types_hash_max_size 2048;

include             /etc/nginx/mime.types;
default_type        application/octet-stream;
include /path/to/my-conf-files/*.conf;

}

11

I may be on to something here:

One permission requirement that is often overlooked is a user needs x permissions in every parent directory of a file to access that file.

12

I don't think that's the problem in this case. If the user didn't have the execute permission, nginx wouldn't be able to determine the existence of the file at all. But we know it does.

You have u+x on all those directories anyway (well, almost all, I can't see /var and /var/www, which you removed from the output for some reason).

The sticky bit on all those directories is not standard either, but it shouldn't technically affect read permissions.

1 Like
13

Here's the full output from the namei command all the way to the root. What do I need to correct in terms of permissions, if anything?

sudo -u nginx namei -l "/var/www/html/.well-known/acme-challenge/-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk"
f: /var/www/html/.well-known/acme-challenge/-o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk
dr-xr-xr-x root root /
drwxr-xr-x root root var
drwxrwsr-x someuser somegroup www
drwxrwsr-x nginx nginx html
drwxr-sr-x nginx nginx .well-known
drwxr-sr-x nginx nginx acme-challenge
-rw-r--r-- nginx nginx -o2BcwO59HZmZur4d0QPEzsyRBMQ3vQSEOfxBbzNoXk

14

I note that the file itself does not have an "x" in the permissions string.

15

Yes, it does not need one. The executable bit for directories is used to grant permission to look inside, but for files, only the read bit is required to actually read them.

I don't see anything wrong with the permissions, and you say that nothing shows up in dmesg -w when you visit the URL, so the culprit is not an LSM like SELinux.

I don't have any ideas.

You could hack it to work needing any files at all using this, but the permission issue isn't making sense to me. I'm off to bed, good luck.

1 Like
16

I already tried stateless mode yesterday. Will try again, but I get the same 403 error.

Thanks for your help _az !

1 Like
17

You may need to remove all the other .well-known and .well-known/acme-challenge locations in your nginx configuration to ensure that the stateless rule is the most specific one.

If you truly get a 403 with stateless, that really makes no sense.

18

Progress! It turns out that SELinux was enabled. I ran

setenforce Permissive

and now I am able to issue a cert.

When SELinux reverts to enforcing again, will this cert be renewed?

How do I resolve this issue for future attempts to issue certs, so that SELinux allows these request? I should try to figure it out myself but any pointers would be greatly appreciated!

1 Like
19

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