Detail: DNS problem: NXDOMAIN looking up A for caop-server.calcomp.com.tw

[Sean]

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.

First of all, I am setting up a gitlab sever in my office, I encounted a DNS problem while installing certbot.

My domain is: caop-server.calcomp.com.tw

I ran this command: sudo certbot certonly --standalone

It produced this output:

sean@opsw-server:~$ sudo certbot certonly --standalone
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Please enter the domain name(s) you would like on your certificate (comma and/or
space separated) (Enter 'c' to cancel): caop-server.calcomp.com.tw
Requesting a certificate for caop-server.calcomp.com.tw

---

Could not bind TCP port 80 because it is already in use by another process on
this system (such as a web server). Please stop the program in question and then
try again.

---

(R)etry/(C)ancel: R

Certbot failed to authenticate some domains (authenticator: standalone). The Cer tificate Authority reported these problems:
Domain: caop-server.calcomp.com.tw
Type: dns
Detail: DNS problem: NXDOMAIN looking up A for caop-server.calcomp.com.tw - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for caop-server.calcomp.com.tw - check that a DNS record exists for this domain

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 web server is (include version): Nginx for Gitlab

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

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):
snap 2.59.4
snapd 2.59.4
series 16
ubuntu 22.04
kernel 5.15.0-73-generic

I am a new guy for programming, thanks for your help.

[danb35]

@Sean

DNS problem: NXDOMAIN looking up A for caop-server.calcomp.com.tw - check that a DNS record exists for this domain

This error message seems entirely straightforward; are you having trouble understanding it? It's saying that there are no DNS records for the domain in question, which is what I'm finding as well. You need to make sure those are present and pointing to the server you're using.

[rg305]

Also:

@Sean

--standalone

@Sean

Could not bind TCP port 80 because it is already in use by another process on
this system (such as a web server). Please stop the program in question and then
try again.

Why use --standalone?
What is using port 80?

[Bruce5051]

Using this online tool https://check-host.net/ easily demonstrates @danb35's comment in post #2 above.
The Permanent link to this check report shows Results of Not found.

[Osiris]

@Sean

I am setting up a gitlab sever in my office

Is that server accessible from the public internet?

[Sean]

@danb35

@Sean

DNS problem: NXDOMAIN looking up A for caop-server.calcomp.com.tw - check that a DNS record exists for this domain

This error message seems entirely straightforward; are you having trouble understanding it? It's saying that there are no DNS records for the domain in question, which is what I'm finding as well. You need to make sure those are present and pointing to the server you're using.

Yes, I can not really understand that since I am not familiar with how DNS/Server works.
I have check with our company's MIS member, they are sure the DNS & the domain name "caop-server.calcomp.com.tw" are correct.
Thanks for your reply

[Sean]

@rg305

Also:

@Sean

--standalone

@Sean

Could not bind TCP port 80 because it is already in use by another process on
this system (such as a web server). Please stop the program in question and then
try again.

Why use --standalone?
What is using port 80?

I just follow the instructions to use --standalone, is there others I can use?. Apache2 use the port, I terminated it and re-try.
Thanks for your replay.

[Sean]

@Bruce5051

Using this online tool https://check-host.net/ easily demonstrates @danb35's comment in post #2 above.
The Permanent link to this check report shows Results of Not found.

Thanks, I saw it. should I ask our company's MIS to make "caop-server.calcomp.com.tw" searchable on the website?

[Sean]

@Osiris

@Sean

I am setting up a gitlab sever in my office

Is that server accessible from the public internet?

No, it is from internal network. is it the problem from internal network?

[rg305]

@Sean

is it the problem from internal network?

When using HTTP validation, the name must be resolvable, and reachable, from the Internet.
If that is not possible, then you can't use HTTP validation.
And must use DNS validation method.

[schoen]

See also

Challenge Types - Let's Encrypt

When you get a certificate from Let’s Encrypt, our servers validate that you control the domain names in that certificate using “challenges,” as defined by the ACME standard.

In order to "validate that you control the domain names in that [requested] certificate", the certificate authority's servers (outside of your network!) must be able to see that you can make a requested change related to those names. That is the proof that you actually control those names.

[Sean]

@schoen

See also

Challenge Types - Let's Encrypt

When you get a certificate from Let’s Encrypt, our servers validate that you control the domain names in that certificate using “challenges,” as defined by the ACME standard.

In order to "validate that you control the domain names in that [requested] certificate", the certificate authority's servers (outside of your network!) must be able to see that you can make a requested change related to those names. That is the proof that you actually control those names.

Thanks, @schoen, I understand.