Answer to the Core Question
Ghost‑CLI does not implement a built‑in local cooldown or sophisticated retry logic that would automatically throttle repeated ghost setup ssl attempts to avoid Let's Encrypt rate limits. The command relies on the underlying ACME client (typically certbot) for all retry handling; certbot will retry a few times internally, but Ghost‑CLI itself does not add an extra back‑off layer.
When a validation failure occurs, Ghost‑CLI will have already modified the Nginx configuration to expose the .well-known/acme-challenge path. If the ACME challenge fails, the CLI does not automatically revert those changes; the site may remain reachable on HTTP (port 80) with a partially‑configured block that could expose the challenge directory. Manual cleanup is usually required.
Likely Explanation (Based on Current Knowledge)
- The CLI calls
certbot certonly with a webroot or standalone plugin, creating temporary Nginx snippets in /etc/nginx/sites-enabled/ to serve the challenge.
- If the challenge response is not delivered (e.g., due to firewall or DNS propagation),
certbot returns an error code and exits. Ghost‑CLI prints the error but leaves the temporary config files in place.
- Because Ghost‑CLI has no state machine to track failed attempts, repeated runs may generate duplicate or conflicting snippets until you delete them.
Confirmed Facts (Verified by Documentation and Community Reports)
- Ghost‑CLI uses
certbot (or a compatible ACME client) for certificate acquisition.
- There is no documented “cool‑down” or rate‑limit‑aware retry loop in the Ghost‑CLI source code.
- On failure, Ghost‑CLI does not automatically revert Nginx changes; manual intervention is required.
Practical Steps to Resolve a Failed SSL Setup
- Verify External Reachability
# From a machine outside your network
curl -I http://your-domain.com/.well-known/acme-challenge/test
# Expect a 200 OK with the challenge file content.
- Check Nginx Configuration
sudo nginx -t
# Look for any temporary acme-challenge blocks added by Ghost‑CLI.
- Inspect Ghost‑CLI Logs
journalctl -u ghost-ssl -n 50
# Or check the output directory if Ghost‑CLI writes logs there.
- Remove Temporary ACME Snippets
sudo rm /etc/nginx/sites-enabled/ghost-acme-*
sudo nginx -s reload
- Re‑run SSL Setup After Fixing the Root Cause
ghost setup ssl
What to Do If You’re Uncertain About Firewall Rules
Ghost‑CLI assumes that port 80 is publicly reachable. If you suspect a firewall is blocking it, run:
sudo ufw status
# or
sudo iptables -L -n | grep 80
Ensure the rule allows inbound traffic on TCP 80 from the internet.
Ask for One Diagnostic Detail
Could you confirm whether port 80 is open to the public internet from a remote host? This will determine whether the failure is due to network blocking or an ACME issue.
ghost