Cloudflare SSL on a VPS: A Practical Setup Without the Gotchas

By Greg Nowak. Updated 1 August 2026.

Putting a VPS behind Cloudflare creates two encrypted connections, not one: the visitor connects to Cloudflare, then Cloudflare connects to your origin server. A browser padlock confirms the first connection. It does not prove that the VPS has the right certificate, cannot be reached around Cloudflare, or will survive a future DNS change.

That distinction matters when a site supports enquiries, payments, customer accounts, or an agency handover. The objective is not merely to “turn on SSL.” It is to leave behind a setup whose certificate choice, redirects, renewal process, and failure modes are understood.

Make the certificate decision first

For a production VPS you control, Full (strict) should normally be the target Cloudflare encryption mode. It encrypts the connection to the origin and verifies that the origin certificate is unexpired, covers the requested hostname, and was issued by a publicly trusted authority or Cloudflare Origin CA.

Flexible leaves the Cloudflare-to-origin leg on HTTP. It can be useful during a constrained migration, but it is a poor final design for a VPS you manage and is a common ingredient in redirect loops.

Operating requirement	Certificate at the VPS	Important consequence
All public traffic remains proxied through Cloudflare	Cloudflare Origin CA	Simple and long-lived, but normal browsers will not trust it when connecting directly.
Monitoring or vendors connect directly to the hostname	Publicly trusted certificate	Direct HTTPS works, provided DNS, routing, and hostname validation are correct.
The Cloudflare proxy may be paused during an incident	Publicly trusted certificate	Avoids certificate warnings during a planned “DNS only” fallback.
The origin must reject traffic that bypasses Cloudflare	Either certificate, plus origin access controls	TLS validation alone does not restrict who can reach the VPS.

A certificate decision matrix based on how the site must operate, not simply which option is easiest to install.

A dependable Nginx setup

For a conventional site that should always run behind Cloudflare, the implementation sequence is straightforward:

Confirm every required hostname, including the apex and www, is present in Cloudflare DNS and proxied.
Create an Origin CA certificate covering those exact hostnames, or obtain a publicly trusted certificate.
Store the private key with restricted permissions. Do not place it in a repository, ticket, or general client handover document.
Configure Nginx to listen on port 443 and use the matching certificate and key.
Validate Nginx before reloading it.
Switch Cloudflare to Full (strict) only after the origin is ready; otherwise visitors can receive a 526 error.
Test the live application, not just its homepage.

A minimal server block looks like this:

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/cloudflare/origin.pem;
    ssl_certificate_key /etc/ssl/private/cloudflare-origin.key;

    root /var/www/example/public;
    index index.html index.php;
}

Then test and reload:

sudo nginx -t
sudo systemctl reload nginx

Paths and application directives will vary, but those two commands belong in the operating procedure. A failed configuration test should stop the deployment before it becomes an outage.

When a public certificate is the better operational choice

An Origin CA certificate is intended for connections from Cloudflare to the VPS. If the proxy is disabled, a visitor connecting directly can see an untrusted-certificate warning. Cloudflare also does not currently send expiry notifications for Origin CA certificates, so record the expiry in your own inventory or monitoring system.

If direct access is part of the operating model, use a publicly trusted certificate and test its automated renewal. With Certbot, the familiar commands remain useful:

sudo certbot --nginx
sudo certbot renew --dry-run

Do not copy an old Certbot installation command without checking the instructions for the VPS operating system. For validation, the ACME HTTP-01 challenge uses port 80. DNS-01 is the practical alternative when that route is unavailable and is required for wildcard certificates. DNS credentials used for automation should be narrowly scoped and protected like any other production secret.

Give redirects one clear owner

Cloudflare, Nginx, and the application may each be capable of enforcing HTTPS or the preferred hostname. That does not mean all three should do it. Assign one layer as the redirect owner and document the decision.

For many business sites, Cloudflare’s Always Use HTTPS is the simplest choice because HTTP requests are redirected at the edge. Cloudflare advises against duplicating this redirect at the origin because conflicting rules can create loops. If Nginx or the application must own redirects instead, disable the overlapping Cloudflare rule and test every hostname.

HTTPS redirection does not repair mixed content. Old http:// image URLs, scripts, fonts, CSS references, and embeds still need investigation. Test forms, login, checkout, admin pages, APIs, webhooks, and OAuth callbacks after changing the scheme or canonical hostname.

Protect the origin separately

Full (strict) authenticates the certificate presented by the VPS; it does not automatically stop direct requests to the server’s IP address. If bypassing Cloudflare would expose an application or avoid its security rules, treat origin restriction as a separate workstream.

Options include allowing only Cloudflare’s current IP ranges at the firewall, using Authenticated Origin Pulls, or adopting a tunnel-based design. Allow for monitoring systems, deployment services, and other legitimate connections before enforcing a block. Roll out the restriction in stages and keep a tested recovery path so a firewall mistake does not lock out the team.

Test the service and leave a usable handover

Before calling the work complete, verify HTTP-to-HTTPS behavior, both canonical hostnames, certificate coverage, forms, authentication, scheduled jobs, callbacks, and monitoring. Review Nginx and application logs for errors that a visual homepage check would miss.

The handover should record the Cloudflare encryption mode, certificate type and expiry, covered hostnames, renewal owner, redirect owner, DNS proxy status, relevant firewall controls, and rollback steps. This is the difference between a configuration that works today and one another operator can safely maintain.

If your Cloudflare and VPS setup has accumulated certificates and redirect rules through trial and error, Greg can review the full path, remove conflicting assumptions, and leave your team with a clearer operating model.