Domain & SSL Issues

DNS not resolving

Common "This site can't be reached" or a DNS_PROBE_FINISHED_NXDOMAIN browser error almost always means the domain's DNS isn't pointed at your server yet, or hasn't propagated.

dig +short example.com

• Prints nothing → the A record isn't set, or hasn't propagated yet. Check your DNS provider's dashboard.
• Prints the wrong IP → the A record points somewhere else (an old host, a placeholder). Update it to your AidiPanel server's IP.
• Prints the right IP, but the site still won't load → DNS is fine; the problem is on the server. See Server & Gateway Errors.

Propagation is usually minutes, occasionally up to 24–48 hours depending on your registrar and the previous record's TTL. If you're actively working on a migration, lowering TTL ahead of time avoids most of this wait.

Browser warning on the panel (port 8443)

Common, and expected This is not a bug. The panel's own login UI uses a self-signed certificate until you attach a real domain to it — see SSL / TLS → Self-signed certificate. Click Advanced → Proceed (exact wording varies by browser) to reach the login page. This warning only ever applies to https://<ip>:8443 — never to your actual sites once SSL is installed on them.

Browser warning on your site

Common during initial setup New sites receive a temporary self-signed certificate so Nginx can serve HTTPS before a trusted certificate is issued. A browser warning is expected until you install or import a trusted certificate.

Most likely: SSL just hasn't been installed for that domain yet.

aidipanel ssl:status

If the domain isn't listed, or shows as self-signed, install a trusted certificate after DNS points to the server:

sudo aidipanel ssl:install --domain example.com --email admin@example.com

If SSL is installed but the warning persists specifically on www.example.com (while the bare domain works fine, or vice versa), verify both names resolve to the server and re-run AidiPanel's certificate installation:

sudo aidipanel ssl:install --domain example.com --email admin@example.com

If you recently changed DNS or moved servers, browsers and OSes cache certificate/DNS state — try a hard refresh or a different network/device to rule out local caching before assuming the server is misconfigured.

"Challenge failed"

Common This is Certbot telling you it couldn't verify domain ownership via the HTTP challenge. Two causes account for nearly all instances of this:

1. DNS hasn't actually propagated yet — go back to DNS not resolving above and confirm dig +short example.com returns your server's IP before retrying ssl:install.

2. Port 80 isn't reachable from the internet:

# Confirm the firewall allows it
ufw status
ufw allow 80/tcp

# Confirm Nginx is actually listening on it
systemctl status nginx
ss -tlnp | grep :80

If you're on a cloud provider (AWS, DigitalOcean, Hetzner, GCP), also check that provider's network-level security group / firewall — UFW being open on the server doesn't help if the cloud provider's firewall in front of it is blocking port 80 separately. This is the single most common miss for people coming from providers with a separate cloud firewall layer.

Too many certificates

Occasional, usually while testing Let's Encrypt allows 5 certificates per exact domain name per week. If you're testing ssl:install repeatedly (deleting and re-issuing while debugging something else), you can hit this limit surprisingly fast.

Use the --staging flag while testing, which issues from Let's Encrypt's staging environment and doesn't count against your real limit (staging certs aren't trusted by browsers, but they confirm the mechanism works):

certbot --nginx --staging -d example.com

Once you're confident it'll work, drop --staging and issue for real — that one issuance counts, but you won't have burned your quota on the debugging attempts.

Certificate not renewing automatically

Rare Renewal is supposed to be silent and automatic. If a certificate is approaching expiry anyway:

# Confirm the renewal cron actually exists and is active
cat /etc/cron.d/aidipanel
systemctl status cron

# Test whether renewal *would* succeed, without actually doing it
certbot renew --dry-run

# Check what happened on the last attempt
tail -50 /var/log/aidipanel-certbot.log

# Force it manually right now
certbot renew --force-renewal --nginx

If --dry-run fails with a DNS or connection error, the cause is the same as Challenge failed above — something changed about DNS or port 80 reachability since the certificate was first issued.

Wildcard certificate challenges

If you're trying to get *.example.com working and hitting issues, remember wildcards require DNS challenge, not HTTP challenge — ssl:install doesn't handle this automatically. See SSL / TLS → Wildcard certificates for the manual Certbot command and the DNS TXT record step it walks you through.