Challenge failed for domain

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: emyjakarta.tech

I ran this command: sudo certbot certonly --expand -d emyjakarta.tech -d www.emyjakarta.tech -d web-01.emyjakarta.tech -d web-02.emyjakarta.tech -d lb-01.emyjakarta.tech

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

How would you like to authenticate with the ACME CA?


1: Nginx Web Server plugin (nginx)
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)


Select the appropriate number [1-3] then [enter] (press 'c' to cancel): 1
Plugins selected: Authenticator nginx, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for web-01.emyjakarta.tech
http-01 challenge for web-02.emyjakarta.tech
nginx: [error] invalid PID number "" in "/run/nginx.pid"
Waiting for verification...
Challenge failed for domain web-01.emyjakarta.tech
Challenge failed for domain web-02.emyjakarta.tech
http-01 challenge for web-01.emyjakarta.tech
http-01 challenge for web-02.emyjakarta.tech
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:

My web server is (include version): nginx/1.18.0 (Ubuntu)

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

My hosting provider, if applicable, is: Amazon.com

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): .tech domain

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

Welcome @Emyjakarta

First, you should update that very old Certbot version. Ubuntu easily supports the recommended snap install. The latest is 2.10

Second, was nginx running before you tried the "expand" command? Because the "invalid PID" can be be caused by Certbot trying to start nginx for you. But, it does not do it in a way compatible with systemd systems. You should restart your server if nginx was not running before the expand command. There are other ways to clean the nginx system up but restarting is easiest if you can tolerate the outage.

Certbot Install instructions

3 Likes

I have updated my certbot version. Yet, it fails to expand the existing certificate. My domain name is emyjakarta.tech. i created the following subdomains, web-01.emyjakarta.tech, web-02.emyjakarta.tech, lb-01.emyjakarta.tech, www.emyjakarta.tech. At present, only https://www.emyjakarta.tech is secured. I want to expand my existing certificate.

ubuntu@527465-lb-01:~$ sudo certbot certonly --expand -d emyjakarta.tech -d www.emyjakarta.tech -d web-01.emyjakarta.tech -d web-02.emyjakarta.tech -d lb-01.emyjakarta.tech
Saving debug log to /var/log/letsencrypt/letsencrypt.log

How would you like to authenticate with the ACME CA?


1: Nginx Web Server plugin (nginx)
2: Runs an HTTP server locally which serves the necessary validation files under
the /.well-known/acme-challenge/ request path. Suitable if there is no HTTP
server already running. HTTP challenge only (wildcards not supported).
(standalone)
3: Saves the necessary validation files to a .well-known/acme-challenge/
directory within the nominated webroot path. A seperate HTTP server must be
running and serving files from the webroot path. HTTP challenge only (wildcards
not supported). (webroot)


Select the appropriate number [1-3] then [enter] (press 'c' to cancel): 1


An RSA certificate named www.emyjakarta.tech already exists. Do you want to
update its key type to ECDSA?


(U)pdate key type/(K)eep existing key type: U
Renewing an existing certificate for emyjakarta.tech and 4 more domains

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: web-01.emyjakarta.tech
Type: unauthorized
Detail: 34.224.62.190: Invalid response from http://web-01.emyjakarta.tech/.well-known/acme-challenge/0YL2PMsSc62AiH7qzFcroRLCiNcWpYjmg45ztFcmYcs: 404

Domain: web-02.emyjakarta.tech
Type: unauthorized
Detail: 34.239.253.87: Invalid response from http://web-02.emyjakarta.tech/.well-known/acme-challenge/uGAGTcyZmKqsyj2F3juA78iSMU-LMjd7LBlKeNjuThE: 404

Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible 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.
ubuntu@527465-lb-01:~$

Your web-01 and web-02 have a different IP than those other names.

The --nginx authenticator only works for domains handled by the nginx system running on the same server as Certbot.

Are these the same server?

dig +noall +answer web-01.emyjakarta.tech
web-01.emyjakarta.tech. 259     IN      A       34.224.62.190

dig +noall +answer emyjakarta.tech
emyjakarta.tech.        240     IN      A       52.91.135.17
4 Likes

lb-01 (52.91.135.17), emyjakarta.tech is my load balancer. i use it to manage the other servers, web-01 (34.224.62.190) and web-02 (34.239.253.87).

Do requests like this reach the same server where you run Certbot "expand" ?

curl -I http://web-01.emyjakarta.tech/.well-known/acme-challenge/Test404
curl -I http://web-02.emyjakarta.tech/.well-known/acme-challenge/Test404

If you need a cert on your load balancer to handle those names shouldn't your DNS for those names point to your LB?

That's how all your other names work (base name, www, and lb-01)

3 Likes

Does it mean that I would have to generate separate SSL certificates for all my servers (individually)? I thought I could use one certificate for all since they belong to the same root domain, emyjakarta.tech.

I am running the certbot command on my load balancer server, lb-01.emyjakarta.tech

ubuntu@527465-lb-01:~$ curl -sI emyjakarta.tech
HTTP/1.1 301 Moved Permanently
content-length: 0
location: https://emyjakarta.tech/

ubuntu@527465-lb-01:~$ curl -sI www.emyjakarta.tech
HTTP/1.1 301 Moved Permanently
content-length: 0
location: https://www.emyjakarta.tech/

ubuntu@527465-lb-01:~$ curl -sI https://www.emyjakarta.tech
HTTP/2 200
server: nginx/1.18.0 (Ubuntu)
date: Sun, 19 May 2024 19:37:01 GMT
content-type: text/html
content-length: 34
last-modified: Sun, 19 May 2024 10:12:42 GMT
etag: "6649d09a-22"
x-served-by: 527465-web-01
accept-ranges: bytes

ubuntu@527465-lb-01:~$ curl -sI http://web-01.emyjakarta.tech
HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Sun, 19 May 2024 19:37:29 GMT
Content-Type: text/html
Content-Length: 34
Last-Modified: Sun, 19 May 2024 10:12:42 GMT
Connection: keep-alive
ETag: "6649d09a-22"
X-Served-By: 527465-web-01
Accept-Ranges: bytes

ubuntu@527465-lb-01:~$ curl -sI http://web-02.emyjakarta.tech
HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Sun, 19 May 2024 19:37:49 GMT
Content-Type: text/html
Content-Length: 34
Last-Modified: Sun, 19 May 2024 10:31:03 GMT
Connection: keep-alive
ETag: "6649d4e7-22"
X-Served-By: 527465-web-02
Accept-Ranges: bytes

ubuntu@527465-lb-01:~$ curl -sI https://www.emyjakarta.tech
HTTP/2 200
server: nginx/1.18.0 (Ubuntu)
date: Sun, 19 May 2024 19:38:41 GMT
content-type: text/html
content-length: 34
last-modified: Sun, 19 May 2024 10:31:03 GMT
etag: "6649d4e7-22"
x-served-by: 527465-web-02
accept-ranges: bytes

ubuntu@527465-lb-01:~$ curl -sI https://www.emyjakarta.tech
HTTP/2 200
server: nginx/1.18.0 (Ubuntu)
date: Sun, 19 May 2024 19:39:00 GMT
content-type: text/html
content-length: 34
last-modified: Sun, 19 May 2024 10:12:42 GMT
etag: "6649d09a-22"
x-served-by: 527465-web-01
accept-ranges: bytes

ubuntu@527465-lb-01:~$ curl -sI https://www.emyjakarta.tech
HTTP/2 200
server: nginx/1.18.0 (Ubuntu)
date: Sun, 19 May 2024 19:39:04 GMT
content-type: text/html
content-length: 34
last-modified: Sun, 19 May 2024 10:31:03 GMT
etag: "6649d4e7-22"
x-served-by: 527465-web-02
accept-ranges: bytes

Can you explain more what you are trying to do?

Because if your LB is terminating SSL from the user-agents (like a browser) then it needs a cert for each of the names it will handle.

The LB makes a separate connection to your "backend" servers. If these are on your same network you may not even need HTTPS and just use HTTP.

But, yes, if you want to use HTTPS between your LB and the backend servers then you must have a cert on each of those servers too. If you get a cert with all the names on the LB you could just copy the needed cert files from there to your "backend" servers. You wouldn't need to setup Certbot on each of them.

If that isn't clear then please explain what you are using as your load balancer (nginx, caddy, ...) and what for your backend. Show an example of your load balancer config that routes traffic to a backend domain.

EDIT: And I repeat, if you want your LB handling all your names the DNS for each name must point to that LB. That isn't where web-01 and web-02 point to right now.

3 Likes

I want my load balancer (lb-01) to point to my root domain, emyjakarta.tech. web-01 would point to a different IP (34.224.62.190) and web-02 will point to another different IP (34.239.253.87).

So, from your explanation, it means that I would generate separate certificates for my web-01 and web-02 servers, right?

Yes, you need to setup a cert for each of those separately on their own servers.

Your LB will need a cert to include the 3 names it does handle. I say 3 names because I assume that lb-01.emyjakarta.tech is your LB? You showed that name in your first post.

Another option is to get a wildcard cert on your LB and then distribute that to your "web" domain name servers. That needs a DNS Challenge which is often more difficult to setup. But might work better overall for you once it is working

3 Likes

It seems to have worked for my load-balancer server. But, it has not yet been activated.
Only https://www.emyjakarta.tech is secure.

ubuntu@527465-lb-01:~$ sudo openssl x509 -in /etc/letsencrypt/live/www.emyjakarta.tech/fullchain.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = Let's Encrypt, CN = R3
Validity
Not Before: May 19 18:57:17 2024 GMT
Not After : Aug 17 18:57:16 2024 GMT
Subject: CN = emyjakarta.tech
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
X509v3 Subject Alternative Name:
DNS:emyjakarta.tech, DNS:lb-01.emyjakarta.tech, DNS:www.emyjakarta.tech

That's because your LB is using a cert that has only that one name in it. And, that cert was created a couple days ago.

I see you got a fresh cert today with all 3 names. You now have to configure your LB to use it. Or, maybe you just need to reload/restart your LB to pickup the new cert.

What is Certbot managing on that LB server. Run this there

sudo certbot certificates
2 Likes

ubuntu@527465-lb-01:~$ sudo certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Found the following certs:
Certificate Name: www.emyjakarta.tech
Serial Number: 3592fc37faefa25631aa5825948e8e25c71
Key Type: ECDSA
Domains: emyjakarta.tech lb-01.emyjakarta.tech www.emyjakarta.tech
Expiry Date: 2024-08-17 18:57:16+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/www.emyjakarta.tech/fullchain.pem
Private Key Path: /etc/letsencrypt/live/www.emyjakarta.tech/privkey.pem


ubuntu@527465-lb-01:~$

It seems like it generated the certificates but it is not yet active.

Certificates don't become "active" on their own; there is no delay period after which the certificate would automatically start to be used.

Certbot and other clients can sometimes install a newly-obtained certificate in a local web server automatically (when you use --nginx Certbot attempts to modify the local nginx configuration to use the new certificate; when you use --apache Certbot attempts to modify the local Apache configuration to use it). If this doesn't happen, or if that server isn't actually the place where the new certificate needs to be used, the new certificate will just sit around not being used! In that case you need to take some kind of action to copy and configure the new certificate and private key into the relevant place where they can be used to secure incoming connections.

If you find a way to do that that can be scripted, Certbot can, for example, run a script specified with the --deploy-hook option whenever a new certificate is obtained. In that case that script can take whatever actions are necessary to deploy the new certificate.

3 Likes

Does your Load Balancer refer to that file?

What software is your load balancer? Did you copy the previous cert to a unique location for it?

4 Likes

the software i used for my load balancer is haproxy.

Do you use SSL Termination or SSL Pass-Thru there?

What kind of server handles your base domain name, www, and lb-01? Does that run on the same machine as haproxy?

When I asked these questions earlier I should have insisted you answer them. It is okay if English is not your first language. Just explain as best you can. It is hard to give advice about more complex server configurations without much info.

4 Likes

Thanks a lot for the guide. I have been able to fix the problem.
I had to adjust the path to the certificates and private key in my haproxy.cfg file to reflect the updated path generated by certbot.
It's now working as expected.

ubuntu@527465-lb-01:~$ curl -sI https://emyjakarta.tech
HTTP/2 200
server: nginx/1.18.0 (Ubuntu)
date: Mon, 20 May 2024 09:06:25 GMT
content-type: text/html
content-length: 64
last-modified: Mon, 20 May 2024 08:42:13 GMT
etag: "664b0ce5-40"
x-served-by: 527465-web-02
accept-ranges: bytes

ubuntu@527465-lb-01:~$ curl -sI https://emyjakarta.tech
HTTP/2 200
server: nginx/1.18.0 (Ubuntu)
date: Mon, 20 May 2024 09:06:33 GMT
content-type: text/html
content-length: 64
last-modified: Mon, 20 May 2024 08:39:26 GMT
etag: "664b0c3e-40"
x-served-by: 527465-web-01
accept-ranges: bytes

ubuntu@527465-lb-01:~$ curl -sI https://lb-01.emyjakarta.tech
HTTP/2 200
server: nginx/1.18.0 (Ubuntu)
date: Mon, 20 May 2024 09:06:51 GMT
content-type: text/html
content-length: 64
last-modified: Mon, 20 May 2024 08:42:13 GMT
etag: "664b0ce5-40"
x-served-by: 527465-web-02
accept-ranges: bytes

ubuntu@527465-lb-01:~$ curl -sI https://lb-01.emyjakarta.tech
HTTP/2 200
server: nginx/1.18.0 (Ubuntu)
date: Mon, 20 May 2024 09:06:55 GMT
content-type: text/html
content-length: 64
last-modified: Mon, 20 May 2024 08:39:26 GMT
etag: "664b0c3e-40"
x-served-by: 527465-web-01
accept-ranges: bytes

ubuntu@527465-lb-01:~$ curl -sI https://www.emyjakarta.tech
HTTP/2 200
server: nginx/1.18.0 (Ubuntu)
date: Mon, 20 May 2024 09:07:05 GMT
content-type: text/html
content-length: 64
last-modified: Mon, 20 May 2024 08:42:13 GMT
etag: "664b0ce5-40"
x-served-by: 527465-web-02
accept-ranges: bytes

ubuntu@527465-lb-01:~$ curl -sI https://www.emyjakarta.tech
HTTP/2 200
server: nginx/1.18.0 (Ubuntu)
date: Mon, 20 May 2024 09:07:09 GMT
content-type: text/html
content-length: 64
last-modified: Mon, 20 May 2024 08:39:26 GMT
etag: "664b0c3e-40"
x-served-by: 527465-web-01
accept-ranges: bytes

ubuntu@527465-lb-01:~$

2 Likes