Why HTTPS Matters for Business Websites
Every business website that handles user data, processes transactions, or collects any form of personal information needs HTTPS. This is not a preference or a nice-to-have feature. Without HTTPS, anyone positioned between your server and your visitors can read, modify, or intercept the data flowing between them. Login credentials, session tokens, contact form submissions, purchase details. All of it readable in plain text on an unencrypted connection.
Business owners sometimes treat HTTPS as a compliance checkbox. Install a certificate, done. But a certificate that is misconfigured, that accepts outdated protocol versions, or that has expired provides a false sense of security without the actual protection. The configuration behind the certificate matters as much as the certificate itself. This guide explains how HTTPS and TLS work, what they protect, where they fall short, and how to implement them correctly on a business website.
How TLS Establishes a Secure Connection
TLS, or Transport Layer Security, is the protocol that powers HTTPS. It starts with a handshake between the client (typically a browser) and your server. The client sends a ClientHello message containing the TLS versions it supports and a list of cipher suites it can use. The server responds with its certificate chain and selects a cipher suite from what the client offered.
The client then verifies the certificate against its trusted Certificate Authority store. Browsers ship with a list of roughly 150 trusted root CAs. If the certificate is signed by one of these trusted authorities, the browser accepts it as valid for the claimed domain. The client generates a random pre-master secret, encrypts it with the server's public key from the certificate, and sends it to the server. The server decrypts this with its private key. Both sides then derive the session key from the pre-master secret.
All subsequent communication for that session uses the session key with symmetric encryption, which is significantly faster than the asymmetric encryption used during the handshake. The certificate authority acts as the trust anchor. A self-signed certificate, where the domain signs its own certificate with its own private key, is not trusted by default because no independent third party has verified that the certificate belongs to the claimed domain.
One practical detail worth understanding: the TLS handshake itself is visible to network observers as a connection establishment event. They can see that a connection was made to your server's IP address, but they cannot see the content of the handshake or what was transmitted after the session key was established.
What HTTPS Protects and Where It Falls Short
HTTPS protects data in transit between the visitor and your server. It prevents eavesdropping, where someone reads the data as it crosses the network. It prevents interception, where someone redirects the data to a different destination. It prevents tampering, where someone modifies the data mid-transit. All of these require a man-in-the-middle position on the network.
The most significant risk HTTPS mitigates for a business website is session hijacking through cookie interception. A session cookie transmitted over plain HTTP can be captured by anyone on the same network and used to impersonate the logged-in user. On sites with user authentication, HTTPS is not optional. It is a fundamental requirement.
HTTPS also protects form data submitted through your website. Contact forms, booking forms, login forms, newsletter signups. All of that data is visible to network observers if the connection is not encrypted. For any site that handles personal information, this is a data protection obligation, not a preference.
What HTTPS does not protect matters just as much. It does not protect data at rest on your server. It does not protect against application logic errors that deliberately disclose information to the wrong user. It does not protect the visitor's device if it has been compromised. A site that uses HTTPS but has SQL injection vulnerabilities is not secure. The HTTPS layer simply means that traffic between server and visitors is encrypted while the SQL injection extracts data through the application layer.
Security depends on the full setup, not just the HTTPS layer. Patch management, access control, secure coding practices, and regular configuration reviews all contribute to a complete security posture.
Certificate Types and Their Appropriate Uses
Domain Validation (DV) certificates verify that the applicant controls the domain name. The Certificate Authority does this by sending an email to an address at the domain or by placing a verification file on the website at a specified path. DV certificates are issued in minutes to hours and are the standard type for most business websites. They provide the same encryption strength as other certificate types. The difference between certificate types is not the encryption level. It is the depth of identity verification behind the certificate.
Organisation Validation (OV) certificates verify domain ownership and confirm that the requesting organisation is a real legal entity. The CA checks company registration records and may contact the company directly. OV certificates display the organisation name in the certificate details when viewed in the browser. OV is appropriate for businesses where identity verification matters, such as financial services or professional services where trust influences purchasing decisions. Modern browsers do not display OV status prominently, so OV's value lies primarily in the verification process itself.
Extended Validation (EV) certificates previously required the most rigorous verification, including domain ownership, organisation identity, physical address, and vetting against fraud databases. EV certificates displayed a green address bar in older browsers. Modern browsers removed this visual indicator, which significantly reduced the practical value of EV certificates for most businesses.
Wildcard certificates cover a domain and all subdomains with a single certificate. A wildcard for *.yourdomain.com covers shop.yourdomain.com, api.yourdomain.com, staging.yourdomain.com, and any other subdomain. Wildcard certificates are convenient but carry higher risk. If the private key is compromised, all subdomains are simultaneously compromised. Use wildcards when managing separate certificates is operationally impractical, not as a default choice.
Obtaining and Installing a TLS Certificate
For most business websites, Let's Encrypt is the correct choice. It provides free DV certificates that are automatically renewed through the Certbot client or hosting provider integration. Let's Encrypt certificates have a 90-day validity, which sounds short but is managed automatically. Automated renewal eliminates the risk of an expired certificate causing an outage. Many hosting providers have Let's Encrypt integration that handles installation and renewal without manual intervention.
When setting up a reverse proxy with HTTPS, you can combine certificate management with your Nginx configuration. A practical approach involves using Certbot to obtain certificates and then configuring Nginx to serve HTTPS alongside your proxy setup.
If you are using a commercial certificate from a vendor, the process involves generating a Certificate Signing Request on your server, submitting the CSR to the Certificate Authority, receiving the certificate and intermediate chain, installing it on your web server, and configuring the server to use the certificate and private key.
Generate the CSR with OpenSSL. The CSR contains your public key and the domain names you want the certificate to cover. The CA uses the CSR to generate the certificate. Keep the private key secure. It must never be transmitted in plain text or stored in a location accessible via the web.
# Generate a 2048-bit RSA private key and CSR
openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.com.key -out yourdomain.com.csr
# You will be prompted for:
# Country Name: GB
# State or Province: West Midlands
# Locality: Coventry
# Organisation Name: Your Business Name Ltd
# Common Name: www.yourdomain.com
# Email: leave blank or use a real address
# Challenge password: leave blank
# Optional company name: leave blankThe Common Name is the most important field. It must match the domain name visitors use to reach your site. If your certificate is for www.yourdomain.com but visitors reach your site at yourdomain.com, browsers show a certificate name mismatch warning. Either get a certificate covering both names or ensure your site redirects consistently from one to the other.
After receiving your certificate, install it alongside the private key on your web server. For Nginx:
# In your Nginx server block for port 443
server {
listen 443 ssl;
server_name www.yourdomain.com;
ssl_certificate /etc/ssl/certs/yourdomain.com.crt;
ssl_certificate_key /etc/ssl/private/yourdomain.com.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
}For Apache:
# In your Apache VirtualHost for port 443
SSLEngine on
SSLCertificateFile /etc/ssl/certs/yourdomain.com.crt
SSLCertificateKeyFile /etc/ssl/private/yourdomain.com.key
SSLCertificateChainFile /etc/ssl/certs/intermediate.crt
SSLProtocol TLSv1.2 TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLOptions +StrictRequire
SSLCompression offRedirect all HTTP traffic to HTTPS so visitors always use the encrypted connection:
# Nginx: redirect all HTTP to HTTPS
server {
listen 80;
server_name www.yourdomain.com;
return 301 https://www.yourdomain.com$request_uri;
}Configuring TLS Protocol Versions and Cipher Suites
Disable TLS 1.0 and TLS 1.1. These are outdated protocol versions with known vulnerabilities including BEAST (Browser Exploit Against TLS), POODLE (Padding Oracle On Downgraded Legacy Encryption), and other attacks. TLS 1.2 and TLS 1.3 are the current standards. Configure your web server to accept only TLS 1.2 and TLS 1.3 and to prefer cipher suites that use forward secrecy.
Forward secrecy, provided by ECDHE cipher suites, ensures that even if your private key is compromised in the future, past sessions cannot be decrypted. The session key was derived from an ephemeral key pair that is not stored after the session ends. Without forward secrecy, an attacker who records encrypted traffic today and later obtains your private key could decrypt all previously recorded sessions.
The cipher suites in the Nginx and Apache examples prefer ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) suites. GCM mode provides authenticated encryption, meaning the ciphertext includes integrity checking and cannot be tampered with without detection. Test your TLS configuration with the SSL Labs Server Test at ssllabs.com. It rates your configuration from A+ to F and identifies specific issues including outdated protocol versions, weak cipher suites, certificate chain problems, and missing security headers. A rating below B typically indicates a configuration issue that should be addressed.
Enforcing HTTPS with HSTS
The HTTP Strict Transport Security (HSTS) header tells browsers to only load your site over HTTPS for the specified duration. Once a browser has received the HSTS header for your domain, it automatically rewrites any HTTP requests to HTTPS, even before the TLS handshake completes. This prevents downgrade attacks where an attacker removes an HTTPS redirect and serves the site over plain HTTP.
# Nginx HSTS header
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
# Apache HSTS header
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"The max-age value is in seconds. 31536000 equals one year. The includeSubDomains flag applies HSTS to all subdomains. The preload flag indicates that you are submitting your domain to the HSTS preload list at hstspreload.org, a list of domains that browsers hard-code to always use HTTPS.
Adding the preload directive is permanent and difficult to reverse. Only add it after you are confident your entire site uses HTTPS consistently and you do not need to serve any HTTP content from your domain or its subdomains. Before enabling HSTS at all, ensure all HTTP content is accessible over HTTPS. If any resource is still served over HTTP, enabling HSTS causes that resource to fail because the browser refuses to request it.
Identifying and Fixing Mixed Content Issues
Mixed content occurs when a page loaded over HTTPS includes resources (images, scripts, stylesheets, iframes) over plain HTTP. Browsers block many types of mixed content by default, which breaks functionality on your site. Other types may load but remain vulnerable to man-in-the-middle modification.
Fix mixed content by updating all hardcoded HTTP URLs to use HTTPS or relative URLs. Use full HTTPS URLs rather than protocol-relative URLs, which modern browsers have deprecated. For same-origin resources, relative URLs work well:
<!-- Before (insecure): -->
<script src="http://cdn.example.com/script.js"></script>
<!-- After (secure): -->
<script src="https://cdn.example.com/script.js"></script>
<!-- Or use a relative URL for same-origin resources -->
<script src="/assets/script.js"></script>Use Content-Security-Policy headers to enforce HTTPS for all resources and detect remaining mixed content:
# Enforce HTTPS and same-origin for all resources
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' https://cdn.yourdomain.com; connect-src 'self'; frame-ancestors 'none'The report-uri directive sends a JSON report to your server when a resource is blocked by the policy. This helps identify mixed content that you have not yet fixed. Your server must log these reports and you should review them regularly until the CSP is clean.
Preventing Certificate Expiry Outages
An expired TLS certificate causes browsers to show a full-page warning that stops most visitors from proceeding. This is one of the most preventable website outages. If you are using Let's Encrypt with Certbot or a hosting provider with auto-renewal, the certificate renews automatically before expiry.
If you are using manual commercial certificates, add the expiry date to your calendar at least 30 days before renewal is due. Monitor certificate expiry with tools like SSLMate's check-cert expiry monitoring, or write a script that checks the expiry date daily and alerts you when renewal approaches:
#!/bin/bash
# Check certificate expiry for yourdomain.com
CERT_FILE="/etc/ssl/certs/yourdomain.com.crt"
DAYS_UNTIL_EXPIRY=$(echo | openssl s_client -servername www.yourdomain.com -connect www.yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates 2>/dev/null | grep notAfter | awk -F'=' '{print $2}' | xargs -I{} bash -c "echo $(( ($(date -d '{}' +%s) - $(date +%s)) / 86400 ))")
if [ "$DAYS_UNTIL_EXPIRY" -lt 30 ]; then
echo "Certificate expires in $DAYS_UNTIL_EXPIRY days" | mail -s "Certificate Expiry Warning" [email protected]
fiIf you manage multiple domains or subdomains, use a centralised certificate monitoring tool rather than relying on individual server checks.
HTTPS and Search Engine Optimisation
Google uses HTTPS as a ranking signal. This does not mean HTTPS directly improves your rankings. It is a minor signal compared to content quality and backlinks. The practical SEO reason to use HTTPS is that Google marks HTTP sites as "not secure" in search results, which affects click-through rates. The browser warning is more impactful than the ranking signal.
If you are migrating an existing site from HTTP to HTTPS, use a 301 permanent redirect from every HTTP URL to its HTTPS equivalent. Update all internal links to use HTTPS. Update absolute URLs in your sitemap, in structured data, and in any API responses that contain URLs. Resubmit your sitemap in Google Search Console for the HTTPS version and monitor for crawl errors during the transition. The migration typically takes two to four weeks for full index transition.
The Business Case for HTTPS
Every business website should use HTTPS. There is no operational reason to run a public business website without encryption. The performance overhead of TLS is minimal, typically under 100 milliseconds on the initial connection, and HTTP/2 often makes sites faster than HTTP/1.1 over plain HTTP because of multiplexing and header compression. HTTP/2 requires HTTPS through ALPN negotiation over TLS.
The cost barrier is gone. Let's Encrypt provides free certificates. The operational complexity argument is reduced by automated renewal tools. The only exceptions are internal development environments that are never exposed to the internet, and specialised use cases where mutual TLS client certificates are required and the server must accept non-TLS connections.
Beyond the technical requirements, HTTPS builds trust. Visitors see the padlock icon in their browser. They see your domain verified by a trusted Certificate Authority. For businesses that handle customer data, this visible verification matters. It signals that you have taken steps to protect their information.