No DNS API?
No problem.
Manual DNS-01.

Before installation or issuance, inspect this machine. If this is an existing certificate, confirm its exact Certificate Name and complete list of domains first. Do not replace a working authenticator or certificate lineage blindly.

cat /etc/os-release | head -n 5
command -v certbot || true
certbot --version 2>/dev/null || true
sudo certbot certificates 2>/dev/null || true
systemctl list-timers --all | grep -i certbot || true

For a new Ubuntu 24.04 VM with no existing Certbot, the Ubuntu APT package includes the built-in manual authenticator. There is no separate manual-DNS plugin to install. If you already use Snap or another Certbot installation, keep that installation and skip this step.

sudo apt update
sudo apt install -y certbot dnsutils
certbot --version

Use only one Certbot installation method per server. Installing additional packages changes your machine; inspect first.

Open a terminal you can leave running. Certbot will pause and display the TXT record name and a fresh value. Do not press Enter yet. Hand the value to the DNS administrator, or paste it into the private-to-your-browser TXT workbench below.

sudo certbot certonly --manual \
  --preferred-challenges dns \
  --agree-tos --email YOUR_REAL_EMAIL@YOUR_DOMAIN \
  --cert-name private-server-1.pri.example.com \
  -d private-server-1.pri.example.com

Important: Use the exact response printed by this Certbot run, never the illustrated example in an older article. DNS-01 does not require the web server to expose port 80 to the public internet.

Leave Certbot waiting. In the DNS workbench, enter the TXT response and copy the record name/value into your real authoritative public DNS. Then check from an internet-connected computer. DNS providers differ: some ask for a record name relative to the zone; others accept the full name.

dig @1.1.1.1 TXT _acme-challenge.private-server-1.pri.example.com +short
dig @8.8.8.8 TXT _acme-challenge.private-server-1.pri.example.com +short

Both queries should show the exact value Certbot provided (possibly surrounded by quotes). These two resolvers are useful checks, not a guarantee that every authoritative DNS server has updated. If the answers are inconsistent, allow more propagation time and check the authoritative nameservers.

Once the correct public TXT response is visible, return to the waiting Certbot terminal and press Enter once. After Certbot reports success, inspect the actual path rather than guessing it.

sudo certbot certificates
sudo openssl x509 -in /etc/letsencrypt/live/private-server-1.pri.example.com/fullchain.pem -noout -subject -issuer -dates

Normally, Certbot stores the chain at /etc/letsencrypt/live/private-server-1.pri.example.com/fullchain.pem and the key at /etc/letsencrypt/live/private-server-1.pri.example.com/privkey.pem. A preexisting name can cause a different lineage; trust the output of certbot certificates.

Issuance does not by itself update Apache or Nginx because certonly obtains the certificate without installing it. Use the corresponding example inside your existing HTTPS virtual host or server block. Do not paste either snippet directly into a terminal or replace a working virtual host blindly.

# Add or update INSIDE the matching <VirtualHost *:443> block:
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/private-server-1.pri.example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/private-server-1.pri.example.com/privkey.pem

sudo a2enmod ssl
sudo apache2ctl configtest
sudo systemctl reload apache2

# Add or update INSIDE the matching server { ... } block:
ssl_certificate /etc/letsencrypt/live/private-server-1.pri.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/private-server-1.pri.example.com/privkey.pem;

sudo nginx -t
sudo systemctl reload nginx

The HTTPS listener, ServerName/server_name, internal DNS, inbound private-network firewall rules, and website root still must be configured for your environment. These are certificate directives, not complete virtual-host files.

openssl s_client -connect private-server-1.pri.example.com:443 \
  -servername private-server-1.pri.example.com < /dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

if sudo openssl x509 -in /etc/letsencrypt/live/private-server-1.pri.example.com/cert.pem -noout -checkend 2592000; then
  echo 'Certificate is not within 30 days of expiration.'
else
  echo 'Manual renewal should be completed now.'
fi

The HTTPS check assumes your internal DNS resolves the hostname to the private server and port 443 is available internally. If DNS is intentionally split, run from an internal client. The expiration command only reads a file - it does not perform renewal.

When the renewal window approaches, repeat the interactive Certbot command on this server, preserving the correct certificate name and all previously covered domains. Each run provides a new DNS challenge. Publish the fresh TXT value, verify public propagation, finish the prompt, then recheck and reload your web server if necessary.

sudo certbot certonly --manual \
  --preferred-challenges dns \
  --agree-tos --email YOUR_REAL_EMAIL@YOUR_DOMAIN \
  --cert-name private-server-1.pri.example.com \
  -d private-server-1.pri.example.com

Not unattended renewal: A cron or systemd timer running certbot renew does not know how to change your DNS without a manual authentication hook. This page intentionally does not install a misleading automatic-renewal job. Check all SANs on existing certificates before renewing; these one-name commands are examples for one-name certificates.