How to Set Up SSL Termination with HAProxy on Ubuntu (HTTPS, Redirects, SNI, and ACME)

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

Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.

To terminate SSL/TLS with HAProxy on Ubuntu, make HAProxy listen on port 443 with ssl and a PEM certificate bundle, then forward decrypted HTTP to your application. Keep a port 80 listener that redirects clients to HTTPS. The essential bind line is bind :443 ssl crt /etc/haproxy/ssl/example.pem.

This guide shows the complete workflow: prerequisites, certificate and private-key handling, a working configuration, validation and reloads, multiple certificates with SNI, backend-encryption choices, ACME renewal, and the failure modes that commonly prevent a deployment from working.

#	Preview	Product	Price
1		Network Security: Private Communication in a Public World (Prentice Hall Series in Computer...	$63.20	Buy on Amazon
2		CompTIA Security+ Certification Kit: Exam SY0-701 (Sybex Study Guide)	$41.83	Buy on Amazon
3		Cybersecurity For Dummies (For Dummies: Learning Made Easy)	$13.53	Buy on Amazon
4		Network Security, Firewalls, and VPNs	$66.62	Buy on Amazon
5		The Practice of Network Security Monitoring: Understanding Incident Detection and Response	$48.65	Buy on Amazon

What SSL termination does in HAProxy

SSL termination means the client-to-HAProxy connection is encrypted, while HAProxy performs the TLS handshake and decrypts the HTTP request. HAProxy then sends the request to a backend server. In the simplest arrangement, the backend connection is ordinary HTTP on a private interface.

1. A client resolves your DNS name to the Ubuntu host and connects to TCP 443.
2. HAProxy presents the certificate selected for the requested hostname and completes the TLS handshake.
3. HAProxy parses the HTTPS request as HTTP and applies frontend rules such as redirects, access controls, logging, and routing.
4. The selected backend receives the request on its configured address and port, such as 127.0.0.1:8080.

The TLS work is attached to the frontend listener. HAProxy’s ssl argument enables TLS encryption on the bind line, and crt identifies the PEM file containing the certificate material and private key.

#1 Best Overall

Network Security: Private Communication in a Public World (Prentice Hall Series in Computer Networking and Distributed Systems)

$63.20

Buy on Amazon

Prerequisites and safety checks

• A DNS name must resolve to the Ubuntu host that will accept the traffic. Test every hostname you intend to place on the certificate.
• TCP 80 and TCP 443 must be allowed by both the host firewall and any upstream network firewall, load balancer, or cloud security group.
• The certificate must cover the requested names through its common name or subject-alternative names. A certificate for one hostname does not automatically cover another.
• HAProxy must be installed and its configuration file location identified. Ubuntu package versions and service-unit names can differ by release.
• An application must be listening on the backend address and port you configure, for example 127.0.0.1:8080.

Treat the private key as a secret. Store it in a directory readable by the HAProxy process (or its administrative group) and by no other accounts. Do not place private keys in a web-accessible directory, source-control repository, shell history, or an unprotected backup.

Install HAProxy and identify the service

Install the HAProxy package supplied for your Ubuntu release, then locate the package’s main configuration file and service unit. A typical Ubuntu package flow is:

sudo apt update
sudo apt install haproxy

Those commands are the conventional package-manager path, but the available HAProxy version, default paths, and service name depend on the Ubuntu release and repository you selected. Read the installed package documentation before enabling the service or using directives that may belong to a newer release.

Before changing production traffic, record the existing configuration and confirm how the service is started and reloaded on this host. Keep a copy of the last known-good file so a failed change can be reverted quickly.

Rank #2

Sale

CompTIA Security+ Certification Kit: Exam SY0-701 (Sybex Study Guide)

$41.83

Buy on Amazon

Build and protect the PEM certificate bundle

For the traditional crt form, HAProxy expects a PEM-formatted file that contains the server certificate and its private key. Put the certificate chain first, followed by the private key, in a file such as /etc/haproxy/ssl/example.pem. If your certificate provider gives you separate files, combine them according to that provider’s instructions and the requirements of your installed HAProxy version.

sudo install -d -m 750 /etc/haproxy/ssl
sudo sh -c 'cat fullchain.pem privkey.pem > /etc/haproxy/ssl/example.pem'
sudo chmod 600 /etc/haproxy/ssl/example.pem

Set the file owner and group to the account that actually reads certificates. Package defaults differ, so determine the HAProxy runtime account instead of assuming a username. The resulting permissions should prevent ordinary users from reading the key while still allowing HAProxy to open it during startup or reload.

Newer HAProxy releases also document separate certificate and key loading through certificate stores. Use those mechanisms only when they are supported by the installed version and when their documented paths and permissions are in place. A single combined PEM file remains the most portable pattern for a basic deployment.

Configure a minimal HTTPS frontend

The following configuration follows HAProxy’s standard TLS and HTTP examples. It terminates TLS on 443, redirects clear-text HTTP from port 80, and sends decrypted requests to an application on port 8080.

Rank #3

Sale

Cybersecurity For Dummies (For Dummies: Learning Made Easy)

$13.53

Buy on Amazon

global
    log /dev/log local0
    log /dev/log local1 notice

defaults
    mode http
    option httplog
    timeout connect 5s
    timeout client 30s
    timeout server 30s

frontend https_in
    bind :443 ssl crt /etc/haproxy/ssl/example.pem
    default_backend app

frontend http_in
    bind :80
    http-request redirect scheme https unless { ssl_fc }

backend app
    server app1 127.0.0.1:8080 check

How the HTTPS bind works

bind :443 opens the HTTPS port on all local addresses. The ssl argument tells HAProxy to perform the TLS handshake. The crt argument points to the PEM bundle. If the file is missing, unreadable, malformed, or lacks the private key, HAProxy will reject the configuration or fail to start.

How the HTTP redirect works

The port 80 frontend accepts an unencrypted request and issues a redirect whose scheme is https. The condition unless { ssl_fc } prevents the rule from redirecting a request that is already encrypted at the HAProxy frontend. In a direct port 80 listener such as the example, requests are not SSL, so the rule redirects them to HTTPS.

If another proxy sits in front of HAProxy and terminates TLS, the meaning of “secure” depends on that proxy’s forwarding and HAProxy’s trust configuration. Do not copy a forwarded-protocol rule without checking the version-specific documentation and your proxy topology; otherwise you can create redirect loops or accidentally treat HTTP as HTTPS.

Validate, reload, and test safely

1. Check every path, certificate, key, and backend address in the file.
2. Run the parser supplied by the installed package:

   sudo haproxy -c -f /etc/haproxy/haproxy.cfg

   Continue only when it reports that the configuration is valid. Parser output usually identifies the line and directive that needs correction.

3. Reload the HAProxy service with Ubuntu’s service manager, using the unit name installed on your system. On systems using the conventional unit, the command is:

   sudo systemctl reload haproxy

   If the unit uses a different name or does not support a graceful reload, follow the package documentation rather than forcing a restart.

4. Request the clear-text URL and verify that it redirects to the HTTPS URL. Test the encrypted URL separately and confirm that the application response is returned.
5. Inspect the certificate presented by the HTTPS endpoint, including its hostname coverage, expiration, and chain. Review HAProxy logs for bind errors, handshake failures, backend connection failures, and redirect behavior.

Test from a network outside the server’s local path when possible. A local request can succeed even when a cloud firewall, NAT rule, or DNS record prevents Internet clients from reaching ports 80 or 443.

Rank #4

Sale

Network Security, Firewalls, and VPNs

$66.62

Buy on Amazon

Use more than one certificate with SNI

Server Name Indication (SNI) lets a client send its requested hostname during the TLS handshake. HAProxy can use that name to select the certificate whose common name or subject-alternative names match. This allows several domains to share one IP address and port.

Loading several certificate files

Depending on the installed version, certificates can be loaded with repeated crt arguments, a directory, or a crt-list. A conceptual repeated-file configuration is:

frontend https_in
    bind :443 ssl crt /etc/haproxy/ssl/example.pem crt /etc/haproxy/ssl/api.example.pem
    default_backend app

For a certificate directory, point the bind option at the directory form documented for your version and ensure that every file has the expected PEM contents and permissions. A crt-list gives you an explicit list of certificates and, where supported, per-certificate options. Follow the syntax of the manual installed with your HAProxy build; certificate-store directives have changed across releases.

Choose a deliberate default certificate

Not every client sends SNI, and a client can request a hostname for which you have no matching certificate. Configure default-crt, or the documented default marker in a crt-list, so an unmatched request receives a deliberate fallback certificate. Without a planned default, clients may see an unexpected certificate or a handshake failure. The fallback certificate should identify a controlled hostname and should not be mistaken for coverage of every domain on the listener.

Best Value

Sale

The Practice of Network Security Monitoring: Understanding Incident Detection and Response

• Used Book in Good Condition

$48.65

Buy on Amazon

SNI deployment checklist

• List every DNS name and map it to the certificate file that covers it.
• Confirm that each certificate includes the exact hostnames clients will request.
• Keep one known-good default certificate for clients with no SNI or unknown SNI.
• Validate the complete bind line before reload; one unreadable certificate can prevent the listener from loading.
• After reload, test each hostname independently rather than testing only the default name.

Decide whether backend traffic should be encrypted

SSL termination and backend encryption are separate decisions. The minimal configuration sends decrypted HTTP from HAProxy to 127.0.0.1:8080. That is often appropriate when the application is on the same host or on a protected private network.

Do not add backend TLS keywords by guesswork. The exact options for enabling encryption and certificate verification depend on the HAProxy version and the backend’s certificate setup. Use the installed configuration manual, then validate the resulting configuration before reloading.

Automate certificates with ACME

HAProxy documents an ACME workflow that can obtain and renew certificates from an ACME provider such as Let’s Encrypt. Automation is useful only when the validation challenge can reach the required public endpoint and the deployment step can place the renewed certificate where HAProxy reads it.

Requirements for an ACME workflow

• The domain’s DNS records must point to the public endpoint that answers the challenge.
• Any challenge-specific HTTP or TLS path must be reachable through firewalls and intermediary proxies.
• The HAProxy version must support the directives and certificate-management workflow you plan to use.
• The account, certificate storage directory, and renewal process must protect private keys with the same restrictive permissions as manually installed keys.
• Renewal must include a deployment action: combine or store the new certificate material, run the HAProxy parser, and perform a graceful reload.

Read the ACME instructions for your installed release before selecting a challenge type. A certificate can renew successfully at the provider while HAProxy continues serving the old certificate if the deployment path, file permissions, or reload step is missing.

Certificate loading options and operational trade-offs

Common failures and recovery steps

HAProxy will not start after the change

• Run haproxy -c -f /etc/haproxy/haproxy.cfg and fix the first reported error.
• Check that every certificate path exists and that the HAProxy runtime account can read it.
• Confirm that the PEM contains both the certificate chain and private key in the expected order.
• Check for a port conflict: another process may already be listening on 80 or 443.
• Restore the last known-good configuration if the service must be returned immediately, then investigate the failed change offline.

The browser reports a certificate warning

• Verify that the client hostname is covered by the certificate’s names.
• Check that HAProxy is presenting the intended SNI certificate rather than the default certificate.
• Confirm that intermediate certificates are included in the served chain.
• Check expiration and ensure the renewed file was deployed and HAProxy was reloaded.

HTTP does not redirect

• Confirm DNS and firewall access to TCP 80.
• Verify that the request reaches the http_in frontend and that the redirect line is inside that frontend.
• Check whether another proxy rewrites the scheme or generates its own redirect.
• Review logs for a listener bound to a different address or port.

HTTPS works but the application is unavailable

• Confirm that the backend process is listening on the exact address and port in the server line.
• Check the backend health result and HAProxy logs.
• Ensure the application accepts the path and Host header that HAProxy forwards.
• If the backend was changed to TLS, verify its certificate trust and the version-specific HAProxy server options.

Only some domains work with SNI

• Test each hostname independently and inspect the certificate returned for each.
• Check spelling and path entries in the directory or crt-list.
• Ensure the certificate files are readable and contain matching private keys.
• Set and test a deliberate default certificate for unknown or non-SNI clients.

Version and change-management considerations

HAProxy syntax and certificate-management capabilities evolve. Legacy combined-PEM configurations are useful for compatibility, while newer releases recommend certificate-store methods for some deployments. Ubuntu package versions also determine the available directives, default service unit, and file layout.

Record the HAProxy version before adopting an example from another release. Validate configuration changes in a staging listener or maintenance window, keep certificate permissions under change control, and make renewal jobs observable by logging both issuance and reload results. A successful parser check proves syntax and file access; it does not prove DNS, firewall reachability, certificate-name coverage, or backend health.

Production readiness checklist

• DNS resolves every intended hostname to the public HAProxy endpoint.
• TCP 80 and 443 are open at every required firewall boundary.
• The certificate names cover each hostname, and the served chain is complete.
• The private key is readable only by HAProxy’s runtime account or administrative group.
• The 443 bind uses ssl and the correct crt, directory, list, or store configuration.
• The 80 frontend redirects to HTTPS with http-request redirect scheme https unless { ssl_fc }.
• The backend address and port are reachable and healthy.
• Configuration parsing succeeds before every reload.
• Each SNI hostname and the fallback certificate have been tested.
• ACME renewal, certificate deployment, parser validation, reload, and failure alerting are all defined if certificates are automated.
• Logs are retained long enough to diagnose handshake, redirect, and backend errors.

Bottom line

A reliable Ubuntu deployment has three essential pieces: a protected PEM certificate bundle, a port 443 HAProxy frontend using ssl crt, and a port 80 frontend that redirects to HTTPS. Add SNI certificate selection when several hostnames share the listener, choose deliberately between HTTP and re-encrypted backend traffic, and make every certificate renewal end with a validated HAProxy reload.

Quick Recap

Bestseller No. 1

Network Security: Private Communication in a Public World (Prentice Hall Series in Computer Networking and Distributed Systems)

$63.20

SaleBestseller No. 2

CompTIA Security+ Certification Kit: Exam SY0-701 (Sybex Study Guide)

$41.83

SaleBestseller No. 3

Cybersecurity For Dummies (For Dummies: Learning Made Easy)

$13.53

SaleBestseller No. 4

Network Security, Firewalls, and VPNs

$66.62

SaleBestseller No. 5

The Practice of Network Security Monitoring: Understanding Incident Detection and Response

Used Book in Good Condition

$48.65

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.