I can't create new certificate i have this issue

Help
1

I don't know how to solve this issue i deleted the past certs i thought the issue there but somthing is redirecting nginx i don't know where..

sudo certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log

No certificates found.

root@ubuntu-s-1vcpu-2gb-70gb-intel-sfo2-01:~# sudo certbot certonly --standalone -d adv-cap.sa -d api.adv-cap.sa
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for adv-cap.sa and api.adv-cap.sa

Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Domain: api.adv-cap.sa
Type: unauthorized
Detail: 134.209.3.5: Invalid response from https://api.adv-cap.sa/.well-known/acme-challenge/AHd7JGv-P4bwkunuNG1K-IvkLYQkcK_74BrWyhxZbcU: 404

Domain: adv-cap.sa
Type: unauthorized
Detail: 134.209.3.5: Invalid response from https://adv-cap.sa/.well-known/acme-challenge/RyDepGNh3nd_3EBi7ua7kcZZ2jLGQAF--ag2mo3EVYY: 404

Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My domain is: adv-cap.sa , api.adv-cap.sa

I ran this command:

standalone, webroot, i also edited default files in nginx but same isssue

It produced this output:
curl -i http://adv-cap.sa/.well-known/ac
me-challenge/test.txt
HTTP/1.1 301 Moved Permanently
Server: nginx/1.29.4
Date: Fri, 03 Apr 2026 11:44:20 GMT
Content-Type: text/html
Content-Length: 169
Connection: keep-alive
Location: https://adv-cap.sa/.well-known/acme-challenge/test.txt

301 Moved Permanently

301 Moved Permanently

nginx/1.29.4

My web server is (include version): Ubuntu 24.04 (LTS) x64

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

nginx

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

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

1 Like
2

Let's start here. There is currently an nginx server replying to HTTPS requests. These use a certificate but you deleted them so something is odd. You should not delete certs if you have an active system using those certs. nginx will not start if its config names a cert file that does not exist.

What do these show?

sudo nginx -t
sudo nginx -v

I am curious what nginx you are controlling because these are some key bits from the nginx that is currently replying (note the -k is needed to ignore the expired cert):

curl -i -k https://adv-cap.sa 

HTTP/1.1 200 OK
Server: nginx/1.29.4
x-nextjs-cache: STALE
X-Powered-By: Next.js

<!DOCTYPE html><html lang="ar"><head><meta charSet="utf-8"/>
<title>Advanced Capability | Advanced Capability</title>
3 Likes
3

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
nginx version: nginx/1.24.0 (Ubuntu)

4

Hmm. That isn't the same version it advertises in the response headers (1.29.4). Are you sure the IP in the public DNS A record (134.209.3.5) is correct? Are you familiar with React framework which is probably being used because of the X-Powered-By header?

HTTP/1.1 200 OK
Server: nginx/1.29.4
x-nextjs-cache: STALE
X-Powered-By: Next.js

And, the nginx -t should have failed if it could not find the cert file. I think either your IP is wrong. Or, you have multiple nginx running on that same machine. Or perhaps are using containers of some kind and the routing between them is wrong.

I showed the title of the web page served for your domain was:
Advanced Capability

Is that what you expect it to have?

2 Likes
5

yes IP is 134.209.3.5 and the what domain shows is actually what is expected to show in website but yes as it shown that the docker container is using nginx 1.29.4 but system nginx 1.24.4

6

It looks like your nginx in docker is the one replying to HTTP requests on port 80.

Is this different than what you did before? Because it now looks like you are trying to use a different nginx system running on your host alongside Certbot to get that.

How were these two nginx setup when you last got a good cert on Dec15 last year?

2 Likes
7

The core issue is that certbot --standalone needs port 80 to itself, but your nginx Docker container is already bound to it. Two clean options depending on your setup:

Option 1 — webroot plugin: If the Docker nginx is your main web server, use certbot's webroot plugin instead of standalone. Point it at the nginx container's webroot volume:

certbot certonly --webroot -w /var/www/html -d adv-cap.sa -d api.adv-cap.sa

Make sure your nginx config inside Docker has a location block serving /.well-known/acme-challenge/ from that same webroot. This way nginx stays running and certbot just drops the challenge file where nginx can serve it.

Option 2 — DNS-01 validation: If you want to avoid HTTP challenges entirely (especially useful when Docker containers make port 80 complicated), switch to DNS-01:

certbot certonly --manual --preferred-challenges dns -d adv-cap.sa -d api.adv-cap.sa

This asks you to create a TXT record at _acme-challenge.adv-cap.sa instead of using port 80 at all. No port conflicts, works regardless of what is listening on 80 or 443. For automated renewal you would need a DNS plugin matching your DNS provider.

Either way, the standalone mode is fighting with Docker for port 80. Webroot or DNS-01 sidesteps that entirely.

1 Like