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: magicom.app
I ran this command:certbot certonly --standalone
It produced this output:
Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Detail: 2606:4700:3034::6815:1826: Invalid response from http://magicom.app/.well-known/acme-challenge/vtN4Lre_wW6Qj3Ah1AlzF8qMz2mooO8hKHNIRKhZxKg: 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.
Maybe it is relevant that I use Cloudflare- Proxy mode?
My web server is (include version): Node JS (guess is NGINX?)
The operating system my web server runs on is (include version):Windows Server 2019
My hosting provider, if applicable, is: Not applicable- dedicted server
I can login to a root shell on my machine (yes or no, or I don't know): I can do a powershell if it is the meaning
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): Nope
The version of my client is (e.g. output of
certbot --version or
certbot-auto --version if you're using Certbot): certbot 1.31.0
How can I resolve it?
Hello @Damit, welcome to the Let's Encrypt community.
Here is a list of issued certificates crt.sh | magicom.app, latest being 2022-09-04.
Let's Debug Challenges all have 2 or more Warnings CloudflareCDN and CloudflareSSLNotProvisioned.
- HTTP-01 Let's Debug
- DNS-01 Let's Debug
- TLS-ALPN-01 Let's Debug
Let’s Encrypt offers Domain Validation (DV) certificates.
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.
Thus you need to own and have control over the Domain Name (or have a subdomain under an existing domain name, for example pointed to your server by your employer or school) you wish to obtain a certificate for, from an ICANN Accredited Registrar.
For Let’s Encrypt to issue a Domain Validation (DV) certificate Domain Validation must happen
and it is a CA/Browser Forum Baseline Requirement.
Best Practice - Keep Port 80 Open
What IP addresses does Let’s Encrypt use to validate my web server?
Let’s Encrypt does not publish a list of IP addresses we use to validate,
and these IP addresses may change at any time.
Let's Encrypt uses Multi-Perspective Validation Improves Domain Validation Security - Let's Encrypt
Since these are Domain Validation (DV) certificates the Domain Name System (DNS) is used extensively in the validation process as well a allowing us to assist here on Let's Encrypt community.
DNS Queries need to give consistent results from any location on the Internet, all your authoritative DNS Servers for the Domain need to also give consistent results as well.
Testing and debugging are best done using the Staging Environment as the Rate Limits are much higher. Rate Limits are per week (rolling).
And to assist with debugging there is a great place to start is Let's Debug.
Im lost here. Sorry...
I use certbot for Windows Server.
What should I do?
I suggest starting here https://certbot.eff.org/ and here Getting Started - Let's Encrypt
Documentation is here Certbot Instructions | Certbot and here Documentation - Let's Encrypt
And patiently wait for more knowledgeable and helpful community volunteers to add their suggestions.
I think the main question for me would be: are you stopping your VOIP web portal software before you run Certbot in standalone mode?
If not, that would explain the 404 error.
Certbot needs exclusive use of port 80 while it issues or renews your certificate, and if the VOIP software is already on port 80, that is a conflict.
This is a bit interesting:
Normally CDNs redirect HTTP to HTTPS.
[but the failure is on HTTP]
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.