How to Install SSL on VPS Without Downtime
Published on November 9, 2026
To install SSL on VPS safely, first confirm that your domain points to the VPS, ports 80 and 443 are reachable, and the web server is already serving the correct site. SSL installation is usually quick. The failures that cause trouble are nearly always DNS, firewall rules, or a virtual-host configuration pointing somewhere unexpected.
A valid certificate encrypts traffic between a visitor and your application. It also enables the browser padlock, protects login sessions and payment forms, and avoids the warning page that sends customers away before your website even has a chance to work. For an ecommerce site, SaaS dashboard, agency client site, or business mailbox portal, this is basic production hygiene.
Before You Install SSL on VPS, Check These Basics
Start by checking the DNS record. Your domain's A record must resolve to the public IPv4 address of the VPS. If you use IPv6, the AAAA record must point to the same server as well. A forgotten AAAA record is a small classic: some visitors reach the new server, while others reach an old one and receive a certificate mismatch.
Next, make sure inbound TCP ports 80 and 443 are open in both places that matter: the VPS firewall and any provider-level firewall. Certbot's common HTTP validation needs port 80 available temporarily or permanently. Your web server must answer requests for the domain on that port.
You should also identify the web server and operating system before changing anything. The commands below assume Ubuntu or Debian with Nginx or Apache. The same certificate concepts apply to AlmaLinux, Rocky Linux, and other distributions, but package names and service commands can differ.
Take a backup of your web server configuration first. A VPS snapshot or a backup of `/etc/nginx/` or `/etc/apache2/` gives you a clean rollback point. It is not dramatic work, just good operations. The future version of you will appreciate it at 2 a.m.
Choose the Right Certificate Route
For most websites, a free Let's Encrypt certificate is the sensible choice. It provides the same transport encryption used by commercial certificates and works well for standard websites, APIs, and control panels. The certificate is valid for 90 days, so automatic renewal is part of the installation, not an optional extra.
A paid certificate can be appropriate when your organization needs a particular validation level, warranty terms, a specific certificate authority, or a managed procurement process. The installation steps are slightly different because you generate a certificate signing request, receive the issued files, and install the certificate chain manually.
If your application runs behind Cloudflare, a load balancer, or another reverse proxy, decide where TLS should terminate. You may need one certificate on the proxy and another between the proxy and VPS. Do not assume that an orange cloud icon or a load balancer removes the need for origin encryption. It depends on the security mode, but end-to-end encryption is normally the correct production setup.
Install a Let's Encrypt Certificate With Certbot
On Ubuntu or Debian, update package information and install Certbot with the plugin for your web server. For Nginx, use:
```bash sudo apt update sudo apt install certbot python3-certbot-nginx ```
For Apache, install the Apache plugin instead:
```bash sudo apt update sudo apt install certbot python3-certbot-apache ```
Before running Certbot, test the web server configuration. For Nginx:
```bash sudo nginx -t ```
For Apache:
```bash sudo apachectl configtest ```
Fix any reported errors before continuing. A certificate request can succeed while the reload fails, leaving the certificate on disk but not active for visitors. The logs are telling the same story now, so read them before adding another moving part.
For an Nginx site, request the certificate and allow Certbot to update the server block:
```bash sudo certbot --nginx -d example.com -d www.example.com ```
For Apache, run:
```bash sudo certbot --apache -d example.com -d www.example.com ```
Replace `example.com` with your actual domain. Only include `www` if it exists in DNS and is configured in the web server. During the prompts, provide a working email address, accept the terms, and choose the redirect option if you want all HTTP traffic sent to HTTPS. In most cases, redirecting is right. It prevents visitors from landing on an unencrypted version of the same page.
Certbot will obtain the certificate, install the paths in the server configuration, and reload the relevant service. Existing HTTP requests may finish normally, and a standard reload does not usually create meaningful downtime. Still, run this during a quieter period if your application has a complex proxy setup or custom rewrite rules.
Install a Commercial SSL Certificate Manually
If you purchased a certificate, create a private key and certificate signing request on the VPS. Keep the private key on the server and never send it by email or place it in a ticket.
```bash sudo openssl req -new -newkey rsa:2048 -nodes \ -keyout /etc/ssl/private/example.com.key \ -out /etc/ssl/certs/example.com.csr ```
Your certificate provider will issue a server certificate and one or more intermediate certificates. Combine intermediates into the full chain if required by your provider. With Nginx, the server block generally needs the following directives:
```nginx listen 443 ssl; server_name example.com www.example.com; ssl_certificate /etc/ssl/certs/example.com.fullchain.pem; ssl_certificate_key /etc/ssl/private/example.com.key; ```
Apache uses equivalent `SSLCertificateFile` and `SSLCertificateKeyFile` directives inside the HTTPS virtual host. The exact file layout can vary by distribution and control panel, so do not paste paths blindly. Verify ownership and permissions as well. The private key should normally be readable only by root and the service account where necessary.
Test the configuration, then reload rather than restart where possible:
```bash sudo nginx -t && sudo systemctl reload nginx ```
A reload retains active worker processes while applying the new configuration. It is the calm option when available.
Verify the Certificate and Redirect Behavior
Open your domain in a private browser window using `https://`. Check that the displayed domain matches the certificate and that the browser reports a valid connection. Then test the HTTP version and confirm it redirects to HTTPS.
From the VPS or another terminal, you can inspect the response headers:
```bash curl -I http://example.com curl -I https://example.com ```
The HTTP request should return a 301 or 308 redirect to the HTTPS address. The HTTPS request should return the expected status, often 200, 301, or 302 depending on your application.
Also inspect the certificate directly:
```bash sudo certbot certificates ```
For a commercial certificate, use OpenSSL to check expiration and issuer details:
```bash openssl x509 -in /etc/ssl/certs/example.com.fullchain.pem -noout -dates -issuer -subject ```
Do not stop at the padlock. Mixed content can still affect pages if scripts, images, fonts, or API calls are loaded with `http://` URLs. Browser developer tools will show these warnings. Update hard-coded URLs, application environment variables, and any CDN or asset settings.
Make Renewal a Monitored Task
Let's Encrypt certificates need renewal before 90 days. Modern Certbot packages typically install a systemd timer automatically, but verify it instead of trusting a quiet server.
```bash sudo systemctl list-timers | grep certbot sudo certbot renew --dry-run ```
The dry run is the meaningful test. It confirms that the VPS can complete future validation and reload the web server after renewal. If it fails, solve that while the existing certificate is still valid.
For commercial certificates, calendar the expiration date well in advance. Renewal is often manual unless your certificate provider or management platform supports automation. Add certificate-expiry monitoring where possible. A valid certificate that expires unnoticed is still an outage, only with a very official-looking browser error.
At kodu.cloud, managed operational support and monitoring can reduce this kind of recurring risk, especially when a VPS hosts several client domains or production services. The goal is simple: certificates should renew quietly, and your team should not need to remember them every quarter.
Common Problems After SSL Installation
A certificate mismatch usually means the request is reaching the wrong VPS, the wrong virtual host is acting as default, or the certificate request omitted a hostname such as `www`. Check DNS first, then inspect the web server's configured server names.
A validation failure normally points to port 80, DNS propagation, or a proxy configuration. If the domain uses a CDN, make sure its DNS records and proxy mode allow the validation method you selected. DNS challenge validation is often better for wildcard certificates, but it requires DNS API access or a manual DNS record process.
If the website redirects in a loop after forcing HTTPS, look for competing redirects in the application, Nginx or Apache, and any reverse proxy. Applications behind a proxy may need a trusted forwarded-header setting so they recognize the original request as HTTPS. This is not the most beautiful DNS situation when it happens, but it is under control once there is one clear owner for redirects.
Keep the certificate, the web server configuration, and renewal checks in the same operational routine. A correctly installed SSL certificate should become boring infrastructure - present, verified, and not asking for attention.
Andres Saar Customer Care Engineer