Should I use acme.sh or Certbot on Linux?

Both are valid. acme.sh is lightweight shell-based and flexible for custom deployments. Certbot is widely documented and very convenient with nginx/apache plugins. Beginners often start with Certbot; advanced users often prefer acme.sh for portability.

What must be ready before issuing a certificate?

Requirements depend on validation method. HTTP-01 needs domain DNS pointing to your server and reachable port 80. DNS-01 does not require A or AAAA records pointing to your server, but does require permission to create _acme-challenge TXT records. In all cases you need Linux sudo access and correct system time.

Can I issue wildcard certificates?

Yes. Wildcard certificates require DNS validation (DNS-01 challenge). HTTP validation cannot issue wildcard certificates.

How does automatic renewal work?

acme.sh installs a cron task, and Certbot uses a cron job or systemd timer depending on your install. Always test renewal with a dry run command and ensure web server reload happens after renewal.

Where should I store certificate files?

Store deployed certificates under stable server paths such as /etc/ssl or /etc/letsencrypt, with restrictive permissions. For acme.sh, use --install-cert to copy to your final paths; do not directly depend on internal files under ~/.acme.sh.

Is this page Linux-only?

Yes. This guide is written for Linux servers and assumes shell access over SSH with sudo permissions.

Linux SSL Certificate Guide (acme.sh & Certbot)

A beginner-friendly Linux guide to install, issue, deploy, verify, and renew free TLS certificates.

Back to Guides · Home

What this page does: it gives you exact Linux commands for your environment and explains each step so a first-time user can still get a working HTTPS certificate.

Scope: Linux servers only. This tool does not sign certificates for you. It helps you run trusted CA workflows (such as Let's Encrypt) on your own server.

1. Validation Method and Command Builder

Method	Best For	Requirements	Wildcard Support
HTTP-01 (webroot)	Running Nginx/Apache site	Port 80 reachable, challenge path writable	No
HTTP-01 (standalone)	Short maintenance window	Port 80 free during issuance	No
DNS-01	Wildcard certificates	DNS TXT update access (manual or API)	Yes

Command Builder Inputs

Choose Your Validation Method

Linux Family

Web Server (deploy/reload)

Certificate Tool

Primary Domain

Additional Domain (optional)

Webroot Path (HTTP webroot only)

Your method selection here controls prerequisites, commands, checks, and troubleshooting shown below.

Install Commands

Issue Commands

Deploy / Web Server Config Commands

Verification Commands

Renewal Commands

2. Prerequisites (auto by selected method)

Domain resolution: your domain should point to your server public IP.
Inbound ports: TCP 80 must be reachable for HTTP-01 challenge (and usually 443 for HTTPS service).
Server access: SSH + sudo on Linux.
System time: NTP/time sync should be healthy.

# HTTP-01: listener and firewall checks
sudo ss -tulpen | grep -E ':80|:443'

# Ubuntu/Debian (UFW)
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status

# RHEL/CentOS/Rocky/Alma (firewalld)
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

# Time sync (all methods)
sudo timedatectl set-ntp true
timedatectl status

DNS control: you can create TXT records for _acme-challenge (manual or API).
No A/AAAA dependency for issuance: DNS-01 validation does not require your domain to point to this server.
Server access: SSH + sudo on Linux.
System time: NTP/time sync should be healthy.

# DNS-01: verify TXT visibility (replace domain)
# If dig is missing:
# Ubuntu/Debian: sudo apt install -y dnsutils
# RHEL/Rocky/Alma: sudo dnf install -y bind-utils

dig +short TXT _acme-challenge.example.com

# Optional: check authoritative DNS answers
dig TXT _acme-challenge.example.com

# Time sync (all methods)
sudo timedatectl set-ntp true
timedatectl status

DNS-01 Add-on: API Automation vs Manual TXT

Option A (recommended): API automation for stable renewals. Example below uses Cloudflare token-based auth.
Option B: Manual TXT records if you do not want to create API tokens. Good for one-off issuance, less convenient for renewal.

Cloudflare API Quick Setup (CF_Token / CF_Account_ID)

Create token in Cloudflare Dashboard → My Profile → API Tokens with Zone:DNS:Edit and Zone:Zone:Read.
Export token in shell as CF_Token.
Get CF_Account_ID from dashboard account overview or by API.

Note: for certbot-dns-cloudflare, API token is usually enough. CF_Account_ID is mainly useful for account identification and some API workflows.

# Set your token
export CF_Token="your_cloudflare_api_token"

# Get account list and IDs
curl -s -X GET "https://api.cloudflare.com/client/v4/accounts" \
  -H "Authorization: Bearer $CF_Token" \
  -H "Content-Type: application/json"

# Use the account that owns your DNS zone
export CF_Account_ID="your_cloudflare_account_id"

If multiple accounts are returned, choose the one that owns your target domain's zone.

Illustrated Cloudflare steps for creating an API token with DNS permissions for ACME DNS-01 — Illustration 1: create a minimum-scope token for DNS automation.

Illustrated Cloudflare steps for finding account ID from dashboard or API — Illustration 2: locate `CF_Account_ID` from dashboard or API.

3. Tool Walkthrough (choose one path)

Select a tool in Step 1. This section will show only the matching walkthrough to avoid mixed instructions.

Path A: acme.sh

A1. Install dependencies

# Ubuntu / Debian
sudo apt update
sudo apt install -y curl socat cron openssl

# RHEL / CentOS / Rocky / Alma
sudo dnf install -y curl socat cronie openssl
sudo systemctl enable --now crond

A2. Install acme.sh

curl https://get.acme.sh | sh -s [email protected]
source ~/.bashrc
acme.sh --version

If command is not found, use ~/.acme.sh/acme.sh directly.

A3. Set Let's Encrypt as default CA

acme.sh --set-default-ca --server letsencrypt
acme.sh --showca

A4. Issue certificate

# Webroot mode
acme.sh --issue -d example.com -d www.example.com -w /var/www/html

# Standalone mode
# Stop web server first (pick one)
sudo systemctl stop nginx
# sudo systemctl stop apache2   # Ubuntu/Debian Apache
# sudo systemctl stop httpd     # RHEL Apache

acme.sh --issue -d example.com -d www.example.com --standalone

# Start web server again (pick one)
sudo systemctl start nginx
# sudo systemctl start apache2  # Ubuntu/Debian Apache
# sudo systemctl start httpd    # RHEL Apache

# DNS wildcard mode (Cloudflare example)
export CF_Token="your_cloudflare_api_token"
export CF_Account_ID="your_cloudflare_account_id"
acme.sh --issue --dns dns_cf -d example.com -d '*.example.com'

A5. Install cert/key into stable paths

sudo mkdir -p /etc/ssl/toolforge/example.com

acme.sh --install-cert -d example.com \
--key-file       /etc/ssl/toolforge/example.com/privkey.pem \
--fullchain-file /etc/ssl/toolforge/example.com/fullchain.pem \
--reloadcmd      "sudo systemctl reload nginx"
# For Apache, replace reload command:
# --reloadcmd    "sudo systemctl reload apache2"   # Ubuntu/Debian
# --reloadcmd    "sudo systemctl reload httpd"     # RHEL

A6. Renewal checks

crontab -l | grep acme.sh
~/.acme.sh/acme.sh --cron --home ~/.acme.sh
~/.acme.sh/acme.sh --renew -d example.com --force

Path B: Certbot

B1. Install Certbot

# Ubuntu / Debian
sudo apt update
sudo apt install -y snapd
sudo snap install core
sudo snap refresh core
sudo snap install --classic certbot
sudo ln -sf /snap/bin/certbot /usr/local/bin/certbot
certbot --version

# RHEL / Rocky / Alma
sudo dnf install -y epel-release
sudo dnf install -y snapd
sudo systemctl enable --now snapd
sudo ln -sfn /var/lib/snapd/snap /snap
sudo snap install --classic certbot
sudo ln -sf /snap/bin/certbot /usr/local/bin/certbot
certbot --version

B2. Issue certificate

# Webroot mode
sudo certbot certonly --webroot -w /var/www/html -d example.com -d www.example.com

# Standalone mode
# Stop web server first (pick one)
sudo systemctl stop nginx
# sudo systemctl stop apache2   # Ubuntu/Debian Apache
# sudo systemctl stop httpd     # RHEL Apache

sudo certbot certonly --standalone -d example.com -d www.example.com

# Start web server again (pick one)
sudo systemctl start nginx
# sudo systemctl start apache2  # Ubuntu/Debian Apache
# sudo systemctl start httpd    # RHEL Apache

# DNS wildcard mode (Cloudflare plugin example)
sudo snap set certbot trust-plugin-with-root=ok
sudo snap install certbot-dns-cloudflare
sudo mkdir -p /root/.secrets/certbot
sudo tee /root/.secrets/certbot/cloudflare.ini >/dev/null <<'INI'
dns_cloudflare_api_token = your_cloudflare_api_token
INI
sudo chmod 600 /root/.secrets/certbot/cloudflare.ini
sudo certbot certonly --dns-cloudflare --dns-cloudflare-credentials /root/.secrets/certbot/cloudflare.ini -d example.com -d '*.example.com'

B3. Renewal checks

sudo certbot renew --dry-run
systemctl list-timers | grep certbot
sudo ls -l /etc/letsencrypt/renewal/

4. Post-Issuance Checks (method-aware)

# HTTP-01 / web deployment checks
# Check cert file dates on server (pick your path)
# certbot path:
sudo openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -noout -dates -issuer -subject
# acme.sh deployed path example:
sudo openssl x509 -in /etc/ssl/toolforge/example.com/fullchain.pem -noout -dates -issuer -subject

# Check live cert from outside
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -dates -issuer -subject

# Check redirect behavior
curl -I http://example.com
curl -I https://example.com

# DNS-01 issuance checks (no HTTP/domain resolution required for validation)
# certbot default path:
sudo ls -l /etc/letsencrypt/live/example.com/
sudo openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -noout -dates -issuer -subject

# acme.sh storage/deploy paths:
ls -la ~/.acme.sh | grep example.com
# if installed to stable path:
sudo ls -l /etc/ssl/toolforge/example.com/
sudo openssl x509 -in /etc/ssl/toolforge/example.com/fullchain.pem -noout -dates -issuer -subject

5. Common Errors and Fixes (method-aware)

Error	Likely Cause	Fix
`Invalid response from /.well-known/acme-challenge`	Port 80 blocked, reverse proxy mismatch, wrong webroot	Open port 80, verify challenge URL path, confirm webroot for the same vhost
`Connection refused` / timeout	Firewall or security group blocks traffic	Allow inbound TCP 80/443 in both cloud and OS firewall
`NXDOMAIN` or DNS validation failure	DNS not propagated or wrong record value	Check with `dig +short example.com` and DNS TXT values
Renewal succeeded but old cert still served	Web server was not reloaded	Configure reload hook/deploy hook and retest
Wildcard issuance failed	Used HTTP challenge	Use DNS-01 challenge only for wildcard certificates

Error	Likely Cause	Fix
`No TXT record found`	TXT record not created at `_acme-challenge` or wrong host	Create exact TXT record name/value and retry after propagation
`Authentication error` from DNS API	Invalid token/account ID or wrong permission scope	Recreate token with required DNS permissions and correct zone scope
`Zone not found`	Token/account does not match target DNS zone	Use account/zone that actually owns the domain
DNS challenge times out	DNS propagation delay	Wait longer, lower DNS cache TTL when possible, then retry
Manual mode cannot auto-renew	Manual TXT mode was used	Switch to API mode for unattended renewal, or renew manually each cycle

Best Practices Checklist

Use one canonical HTTPS host and redirect all variants.
Protect private keys with restrictive permissions.
Run nginx -t or apachectl configtest before reload.
Test renewal monthly even if automation is enabled.
Never commit DNS API tokens to repositories.

References

Frequently Asked Questions

Should I use acme.sh or Certbot on Linux?: Both are valid. acme.sh is lightweight shell-based and flexible for custom deployments. Certbot is widely documented and convenient with nginx/apache plugins.
What must be ready before issuing a certificate?: Requirements depend on validation method. HTTP-01 needs DNS pointing to your server and reachable port 80. DNS-01 does not require A/AAAA pointing to your server, but does require control of _acme-challenge TXT records. In all cases you need Linux sudo access and correct system time.
Can I issue wildcard certificates?: Yes, but only through DNS-01 validation.
How does automatic renewal work?: acme.sh uses cron; Certbot uses cron or systemd timer. Always test with dry-run commands.
Where should I store certificate files?: Use stable paths under /etc/ssl or /etc/letsencrypt, with strict permissions.
Is this page Linux-only?: Yes. Commands and service management examples are for Linux servers.