How to Set Up Free HTTPS with Let’s Encrypt on a VPS

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.

You can secure a VPS-hosted website at no certificate cost with Let’s Encrypt and Certbot. Point the domain at the server, make the site reachable through the challenge you choose, run Certbot for nginx or Apache (or use its webroot, standalone, or DNS mode), then test renewal with a dry run. Let’s Encrypt certificates are valid for 90 days, so an automated renewal timer is part of a correct installation—not an optional follow-up.

For a normal public website, use HTTP-01 with the nginx or Apache installer. Use DNS-01 when inbound port 80 cannot be reached, the origin is private, or you need a wildcard such as *.example.com.

What you need before installing HTTPS

HTTPS validation proves that you control the domain. Your VPS must therefore be able to answer the validation request or update the domain’s DNS record, depending on the challenge.

• A registered domain: Replace example.com in the commands below with your name.
• Correct DNS: The domain’s A record should resolve to the VPS’s public IPv4 address. If you publish an AAAA record, it must point to a working IPv6 address on the same service; an incorrect AAAA record can send validation to the wrong machine.
• A running web server: nginx or Apache should serve the intended site and have a virtual host for the domain.
• Firewall and provider rules: For HTTP-01, inbound TCP port 80 must be allowed by the VPS firewall and by the cloud provider’s security group or network ACL. HTTPS clients will also need TCP port 443 after installation.
• Administrative access: You need root or sudo privileges to install Certbot, edit web-server configuration, and bind to port 80 when using standalone mode.

VPS users normally manage their own Certbot installation. This differs from some managed hosting products where the provider installs and renews certificates for you.

Choose the right ACME challenge

Certbot is an ACME client. It asks Let’s Encrypt to issue a certificate and completes one of Let’s Encrypt’s domain-control challenges. Select the method before running a command; the network requirements and renewal behavior differ.

Method	Best fit	Network requirement	Wildcard certificates	Renewal behavior
nginx or Apache installer	An existing supported web server whose HTTPS configuration can be edited by Certbot	HTTP-01 normally requires inbound port 80	No; use DNS-01 for a wildcard	Automatic when Certbot’s timer or cron job is working
Webroot	A running server with a document root you control	HTTP-01 and reachable port 80	No	Automatic with the saved plugin configuration
Standalone	No usable web-server integration	Certbot temporarily binds port 80, so another service must stop or be coordinated	No	Automatic if port 80 can be made available at renewal time
DNS-01	Port 80 is blocked, the origin is private, or a wildcard is required	A TXT record under _acme-challenge, usually through a DNS API	Yes	Automate with a supported DNS plugin or authentication hook
Manual	One-off or unusual validation where you perform each challenge yourself	You complete the HTTP or DNS steps interactively	Yes, when using the DNS challenge	No automatic renewal unless an authentication hook script is added

How HTTP-01 works

Certbot creates a token file at /.well-known/acme-challenge/<TOKEN>. Let’s Encrypt retrieves that file over ordinary HTTP and checks that the response matches the token. The nginx, Apache, webroot, and standalone plugins use this challenge. Standalone mode needs to bind to port 80 temporarily, even if your normal site uses another server.

How DNS-01 works

Certbot (or you, in manual mode) publishes a TXT record beneath _acme-challenge.example.com. Let’s Encrypt checks DNS rather than connecting to the VPS. DNS-01 is the only challenge that can issue a wildcard certificate. The challenge name can also be delegated with CNAME or NS records, which is useful when DNS is hosted separately from the VPS.

Install Certbot on a Debian or Ubuntu VPS

The exact package source depends on your distribution image. On a current Debian- or Ubuntu-based VPS, the distribution packages commonly use commands like these:

sudo apt update
sudo apt install certbot

Install the web-server integration you intend to use:

# nginx
sudo apt install python3-certbot-nginx

# Apache
sudo apt install python3-certbot-apache

Check that the client is available:

certbot --version

On another Linux distribution, use that distribution’s documented Certbot package method. Do not install two unrelated Certbot copies and expect their timers or configuration to be interchangeable.

Set up HTTPS on nginx

1. Confirm the HTTP virtual host

Before requesting a certificate, make sure nginx has a server block whose server_name matches every name you will request. A minimal example is:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    root /var/www/example;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Place the file in the location used by your distribution, enable it if necessary, then validate and reload nginx:

sudo nginx -t
sudo systemctl reload nginx

From a different network, request http://example.com and verify that the expected site—not a default page or another virtual host—responds. Resolve the name with both IPv4 and IPv6 if both records exist.

2. Back up the configuration

Certbot’s nginx installer can edit server blocks and provides rollback support, but keep your own copy before an automated change:

sudo cp -a /etc/nginx /etc/nginx.backup-before-certbot

3. Obtain and install the certificate

Run the nginx installer with each hostname that should appear in the certificate:

sudo certbot --nginx -d example.com -d www.example.com

Certbot performs the HTTP-01 validation, obtains the certificate, and offers to update nginx for HTTPS and HTTP-to-HTTPS redirection. Read the proposed names and redirect choice carefully. If validation succeeds but you want to edit the TLS policy yourself, obtain the certificate without changing nginx instead:

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

Certificates and private keys are normally placed under /etc/letsencrypt/live/<certificate-name>/, with fullchain.pem for the server certificate chain and privkey.pem for the private key. Let Certbot manage these paths rather than copying dated files into your configuration.

4. Verify nginx after the change

sudo nginx -t
sudo systemctl reload nginx

Visit both the bare domain and www name over HTTPS. Confirm that the browser shows the expected hostname, the page loads without mixed-content errors, and an HTTP request follows the redirect you selected.

Set up HTTPS on Apache

1. Prepare the name-based virtual host

Ensure Apache has an enabled port-80 virtual host with the correct ServerName and any required ServerAlias. The site must be reachable at the exact names supplied to Certbot.

2. Back up and test Apache

sudo cp -a /etc/apache2 /etc/apache2.backup-before-certbot
sudo apachectl configtest

Fix configuration errors before requesting a certificate. A failed validation caused by a broken virtual host is easier to diagnose before HTTPS changes are introduced.

3. Run the Apache installer

sudo certbot --apache -d example.com -d www.example.com

The Apache plugin can obtain the certificate and install the SSL virtual-host directives. If you want Certbot to obtain files only, use:

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

After either flow, test and reload Apache:

sudo apachectl configtest
sudo systemctl reload apache2

Open the HTTPS URL in a browser and check every requested hostname. A certificate for example.com does not automatically cover www.example.com; include both names when you need both.

Use webroot when the server must stay running

The webroot plugin leaves nginx or Apache running and writes the temporary token into the site’s document root. This is useful when you control the root directory but do not want Certbot to rewrite the server configuration.

1. Make the challenge directory reachable

For a site rooted at /var/www/example, create a test file:

sudo mkdir -p /var/www/example/.well-known/acme-challenge
printf 'challenge-testn' | sudo tee /var/www/example/.well-known/acme-challenge/test.txt

Request http://example.com/.well-known/acme-challenge/test.txt from outside the VPS. It must return the file contents, not a redirect to an application route, authentication prompt, or custom 404 page. Remove the test file afterward.

In nginx, an explicit location can prevent application routing from intercepting the token:

location ^~ /.well-known/acme-challenge/ {
    root /var/www/example;
    default_type text/plain;
    try_files $uri =404;
}

Apache must likewise allow ordinary access to that directory; do not place a rule there that requires login or blocks hidden paths.

2. Request the certificate

sudo certbot certonly --webroot 
  -w /var/www/example 
  -d example.com -d www.example.com

After issuance, configure nginx or Apache to use the resulting certificate paths, then reload the server. The same webroot mapping is saved for renewal, so keep the directory and its permissions stable.

Use standalone mode when no web-server plugin fits

Standalone mode starts a temporary Certbot listener on port 80. Stop the service that currently owns that port, issue the certificate, and start the service again:

sudo systemctl stop nginx
sudo certbot certonly --standalone -d example.com -d www.example.com
sudo systemctl start nginx

Use apache2 instead of nginx for an Apache service. This causes a short interruption and will fail if another process, firewall, or provider rule still occupies or blocks port 80. Renewal must be able to repeat the stop/start coordination; otherwise choose webroot, an installer plugin, or DNS-01.

Use DNS-01 for blocked port 80 or wildcard names

Automated DNS validation

When your DNS provider has a supported Certbot plugin, install that plugin and grant it permission to create and remove only the required TXT records. Plugin package names and command-line options vary by provider, so follow that provider’s current plugin documentation rather than copying an option intended for a different DNS service. A typical automated flow has the form:

sudo certbot certonly 
  --dns-<provider> 
  -d example.com -d '*.example.com'

The wildcard name must be quoted so the shell does not expand the asterisk. Request the base name separately when clients must connect to example.com; a wildcard covers subdomains but not the apex name itself.

Manual DNS validation

For a one-time test or an unsupported DNS provider, run:

sudo certbot certonly --manual 
  --preferred-challenges dns 
  -d example.com -d '*.example.com'

Certbot displays a TXT value. Create it at _acme-challenge.example.com, wait for the record to be visible through public DNS, and continue when prompted. DNS propagation time is outside Certbot’s control. Verify the exact record name and value; leaving an old TXT value in place can make troubleshooting harder.

Manual certificates do not renew automatically unless you supply an authentication hook script that repeats the DNS or HTTP work. For a long-lived VPS, an API-driven DNS plugin or a carefully maintained hook is safer than scheduling a person to repeat the prompt every few months.

Protect DNS credentials

A DNS API token can often change far more than the single TXT record needed for validation. Do not place broad DNS credentials in a public web directory or in an application’s environment when a narrowly scoped token is available. A compromise of the VPS holding broad DNS credentials could let an attacker alter other records or redirect the domain. Let’s Encrypt recommends narrowly scoped credentials or a separate validation server for this reason.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Test HTTPS and certificate details

After installation, check each name over HTTPS:

1. Open https://example.com and any aliases such as https://www.example.com.
2. Inspect the browser’s certificate details. Confirm the subject/SAN list contains the hostname, the issuer is trusted, and the expiration date is in the future.
3. Request the HTTP URL and confirm that your intended redirect reaches HTTPS without a loop.
4. Check application assets, APIs, webhooks, and health checks. A page can show a lock while a script, image, or API still uses an insecure URL.

Let’s Encrypt’s standard certificate profile is valid for 90 days. The organization explains that this lifetime is intended to make automation normal while leaving enough time for manual work: “We chose 90-day lifetimes for our initial offering because ninety days was short enough to strongly encourage automation, but long enough to make it possible to do things manually.” Let’s Encrypt also publishes an approximately six-day short-lived profile; if you select that profile, unattended renewal and rapid recovery are even more important.

Configure and test automatic renewal

Understand what certbot renew does

The renew action examines every certificate previously obtained by Certbot and renews only certificates that are close to expiry. Running it regularly is safe; it does not request a new certificate on every invocation. When a certificate is renewed, Certbot can reload the web server through the installer or a configured deploy hook.

Check the installed timer or cron job

Certbot packages commonly install a systemd timer or cron job. Inspect both the timer and its recent logs on a systemd-based VPS:

systemctl list-timers --all | grep -i certbot
sudo journalctl -u certbot.timer --since today

If your distribution uses cron instead, inspect the system cron locations and the package’s Certbot entry. Confirm that the job runs as root and that the VPS can reach Let’s Encrypt and your DNS API, if you use DNS-01.

Run the required dry run

Test the complete renewal path before relying on it:

sudo certbot renew --dry-run

A successful dry run exercises the saved authenticator and server integration without waiting for the 90-day certificate to approach expiration. Treat any error as a setup failure: fix DNS, port access, webroot permissions, plugin credentials, or service hooks and repeat the test.

Observe a real renewal

Do not delete a working production certificate merely to force a renewal. After the dry run, monitor the timer logs and Certbot’s renewal configuration under /etc/letsencrypt/renewal/. When a production renewal occurs, verify the new expiration date and confirm that nginx or Apache reloaded the renewed files.

Troubleshoot common failures

Symptom	Likely cause	What to check
Connection refused or timeout during HTTP-01	Port 80 is blocked or another address answers	Cloud firewall, local firewall, listening sockets, A/AAAA records, and the VPS’s public IP
404 for the challenge file	Wrong document root or an application route intercepts /.well-known	Create a public test file and verify the exact URL from outside the server
Validation reaches a default site	Missing or incorrect server_name/ServerName	Ensure the requested hostname maps to the intended virtual host on port 80
DNS-01 record not found	Wrong record name, stale propagation, or API token changed another zone	Query the public TXT record and compare its value character-for-character with Certbot’s prompt
Standalone says port 80 is busy	nginx, Apache, a container, or another process still owns the port	Run sudo ss -ltnp 'sport = :80', stop or coordinate the owner, then retry
Renewal dry run fails after a successful first issue	DNS credentials expired, the webroot moved, a firewall changed, or the timer is missing	Run the dry run manually, read its error, and inspect the saved renewal configuration and timer
Browser warns about an incomplete chain	The server is presenting only the leaf certificate	Configure fullchain.pem, not just cert.pem, and reload the server

Operational practices that prevent outages

• Keep port 80 available for HTTP-01 even if every normal request redirects to HTTPS. The challenge request still begins as HTTP.
• Use certbot certonly when you need full control over an established configuration; use the nginx or Apache installer when its edits match your operating model.
• Back up server configuration before an installer change and run the server’s syntax test before every reload.
• Keep the .well-known/acme-challenge path publicly readable when using webroot. Do not require application authentication there.
• Store private keys with restrictive permissions and limit shell access to administrators who need certificate maintenance.
• For DNS-01, issue the smallest API token your provider supports and keep it off the public document root. Rotate it if the VPS is compromised.
• Test renewal after firewall, DNS, webroot, web-server, or provider changes. A certificate that works today can still expire later if the renewal path no longer works.

Which setup should you choose?

Choose the nginx or Apache installer for a conventional public site when you are comfortable letting Certbot add HTTPS directives and redirects. Choose webroot when the service must remain running and you already know the document root. Choose standalone only when no integration is practical and you can reliably free port 80 during every renewal. Choose DNS-01 for blocked port 80, private origins, delegated validation, or wildcard certificates. Avoid manual validation for unattended production systems unless you have an authentication hook that automates the same steps.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.