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. https://crt.sh/?q=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: jbdnts.info
I ran this command: From NPM attempting both from the proxy host and requesting *.jbdnts.info with cloudflare api token
It produced this output: Command failed: certbot certonly --config "/etc/letsencrypt.ini"
My web server is (include version): PorkBun through CloudFlare
The operating system my web server runs on is (include version): Ubuntu Server 20.04 on RPI4; Also trying to make it work on Linux Mint 19 -- both using Docker
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): no
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
I've searched, install/reinstal on both Mint and RPI4, same result. Ports 80/443 open in Router and Firewall shows them allowed. Not proxied in Cloudflare to allow SSL. I'm at a loss. Help!
Hi @joebagodonuts and welcome to the LE community forum
You must have a working HTTP site before it can be secured (via HTTP authentication).
If you are using CloudFlare CDN, why not just use their certs?
? aren't I requesting cert from cloudflare via NPM? I'm missing something; you saying make nginx/wordpress site through a hosting company or something?
The topic title says:
"NPM won't create LetsEncrypt Certificate"
Your post is on the LE community forum.
What did I miss?
logs ref'd this site for help. Guess I'll try elsewhere
In the (near) future, it would be very helpful to include (relevant parts of) those logs. Currently, the only thing you've stated so far (besides the mandatory questions) is "Command failed", which doesn't help people very much.
You should probably understand that we don't have a crystal ball to look into and we must work with the information you provide: the more the better.
It's been awhile since I posted code, hopefully I hit the right button
Connection Error: Error: read ECONNRESET
[1/18/2022] [8:32:18 AM] [Nginx ] › ℹ info Reloading Nginx
[1/18/2022] [8:32:18 AM] [SSL ] › ℹ info Requesting Let'sEncrypt certificates via Cloudflare for Cert #9: *.jbdnts.info
[1/18/2022] [8:32:18 AM] [SSL ] › ℹ info Command: mkdir -p /etc/letsencrypt/credentials 2> /dev/null; echo '# Cloudflare API token
dns_cloudflare_api_token = REMOVED' > '/etc/letsencrypt/credentials/credentials-9' && chmod 600 '/etc/letsencrypt/credentials/credentials-9' && pip install certbot-dns-cloudflare==$(certbot --version | grep -Eo '[0-9](\.[0-9]+)+') cloudflare && certbot certonly --config "/etc/letsencrypt.ini" --cert-name "npm-9" --agree-tos --email "x@x" --domains "*.jbdnts.info" --authenticator dns-cloudflare --dns-cloudflare-credentials "/etc/letsencrypt/credentials/credentials-9"
[1/18/2022] [8:32:29 AM] [Nginx ] › ℹ info Reloading Nginx
[1/18/2022] [8:32:29 AM] [Express ] › ⚠ warning Command failed: certbot certonly --config "/etc/letsencrypt.ini" --cert-name "npm-9" --agree-tos --email "x@x" --domains "*.jbdnts.info" --authenticator dns-cloudflare --dns-cloudflare-credentials "/etc/letsencrypt/credentials/credentials-9"
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Error determining zone_id: 9109 Cannot use the access token from location: x.x.x.x. Please confirm that you have supplied valid Cloudflare API credentials. (Did you enter a valid Cloudflare Token?)
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.
I've edited your post and removed the Cloudflare token. However, it has been publicly shown on the internet and a select group of higher level users here can access the edit history. You should inactivate your current token immediately.
Also, what kind of software puts credentials like that in the log file?!?
FWIW. I deactivate/re-activated the cloudflare site so hopefully that helps, That was from docker log.
The error seems to suggest that that token wasn't actually the right token from Cloudflare, or didn't have the right permissions to make the relevant DNS changes. Cloudflare accounts can have many different kinds of authentication credentials associated with them; are you sure that you chose the right one here?
thought I was on to something by trying to use webroot ref's at https://community.letsencrypt.org/t/solved-redo-first-time-certbot-certificate-installation-start-over/59520 but no go, docker log again shows
Connection Error: Error: read ECONNRESET [1/19/2022] [4:03:23 AM] [Nginx ] › ℹ info Reloading Nginx [1/19/2022] [4:03:28 AM] [SSL ] › ℹ info Requesting Let'sEncrypt certificates for Cert #2: jbdnts.info [1/19/2022] [4:03:28 AM] [SSL ] › ℹ info Command: certbot certonly --config "/etc/letsencrypt.ini" --cert-name "npm-2" --agree-tos --authenticator webroot --email "x@x" --preferred-challenges "dns,http" --domains "jbdnts.info" [1/19/2022] [4:03:45 AM] [Nginx ] › ℹ info Reloading Nginx [1/19/2022] [4:03:45 AM] [Express ] › ⚠ warning Command failed: certbot certonly --config "/etc/letsencrypt.ini" --cert-name "npm-2" --agree-tos --authenticator webroot --email "x@x" --preferred-challenges "dns,http" --domains "jbdnts.info" Saving debug log to /var/log/letsencrypt/letsencrypt.log 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. The only other ref was
please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
So far as I can tell cloudflare is showing my public facing IP and my router is forwarding 80/443 and firewall is allowing the same.
nginx is unreachable.
You must have a working HTTP site before you can secure it (via HTTP authentication).
curl -Ii 188.8.131.52
curl: (56) Recv failure: Connection reset by peer
curl -Ii jbdnts.info
curl: (56) Recv failure: Connection reset by peer
that's the public facing IP, i.e., not proxied by cloudflare, in order to get LE SSL from NPM. I think I'm coming to the conclusion that I need to put up a vanilla wordpress site and try SSL from there?
You don't actually need a website.
certbot can be used to satisfy the HTTP challenge request in
User Guide — Certbot 1.22.0 documentation (eff-certbot.readthedocs.io)
[you will need for the Internet IP:80 to be able to reach the internal IP:80]
have now tried standalone, had to stop half a dozen service on docker to unbind 80, still timed out with
Failed authorization procedure. jbdnts.info (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain
probably wrong but as I see docker containers using pihold/8083:80, npm/80:80, wordpress/8081:80 etc., I see those encumbering port 80. I'm probably wrong, but that's how I read it.
That seems overloaded but shouldn't be part of the problem.
Can you run (within the container) ?:
netstat -pant | grep 80 | grep -i listen
I've alreade restarted NPM, in that path I ran the netstat, I get the below (as root)
root@mint:/docker/proxymanager# netstat -pant | grep 80 | grep -i listen
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 5971/docker-proxy
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 2183/docker-proxy
tcp 0 0 0.0.0.0:8081 0.0.0.0:* LISTEN 5026/docker-proxy
tcp 0 0 0.0.0.0:8082 0.0.0.0:* LISTEN 1932/docker-proxy
tcp 0 0 0.0.0.0:8083 0.0.0.0:* LISTEN 10959/docker-proxy
tcp 0 0 0.0.0.0:8085 0.0.0.0:* LISTEN 2442/docker-proxy
tcp 0 0 0.0.0.0:5080 0.0.0.0:* LISTEN 10920/docker-proxy
tcp 0 0 0.0.0.0:8443 0.0.0.0:* LISTEN 2680/docker-proxy
tcp 0 0 0.0.0.0:8096 0.0.0.0:* LISTEN 7481/docker-proxy
tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN 4206/docker-proxy
tcp 0 0 0.0.0.0:5800 0.0.0.0:* LISTEN 11046/docker-proxy
Well, (whatever) that is using port 80.
Is that inside or outside of the container?
[looks like outside]