Before You Start
- Administrative access to your web server (Apache, Nginx, IIS, or cloud platform)
- A domain name with DNS control for certificate validation
- Basic understanding of web server configuration files
- SSH or remote desktop access to the server
Obtain a TLS certificate from a trusted certificate authority
Every HTTPS connection requires a valid TLS certificate issued by a trusted certificate authority. For most SMBs, Let us Encrypt provides free certificates that are trusted by all major browsers and can be automated with tools like Certbot. For organizations requiring extended validation or wildcard certificates, commercial CAs like DigiCert, Sectigo, or GlobalSign offer paid options. To obtain a certificate, generate a certificate signing request on your server that includes your domain name. For Let us Encrypt with Certbot, run certbot certonly with the webroot or standalone plugin and specify your domain. Certbot handles the CSR generation, domain validation, and certificate installation automatically. For commercial CAs, submit the CSR through their web portal, complete domain validation via DNS or email, and download the issued certificate files including the intermediate certificate chain.
Install the certificate and configure the certificate chain
Install the certificate on your web server along with the complete certificate chain. The chain includes your server certificate, any intermediate certificates, and the root certificate. Missing intermediates are one of the most common TLS configuration errors and cause trust failures on some clients. For Nginx, set the ssl_certificate directive to a file containing your server certificate followed by the intermediate certificates concatenated in order. Set ssl_certificate_key to your private key file. For Apache, use SSLCertificateFile for the server certificate, SSLCertificateKeyFile for the private key, and SSLCertificateChainFile for the intermediate certificates. For IIS, import the PFX file through the Server Certificates feature in IIS Manager and bind it to your HTTPS site. Verify the chain is complete using an online tool like the SSL Labs server test.
Configure supported protocol versions
Disable outdated protocol versions and enable only TLS 1.2 and TLS 1.3. TLS 1.0 and 1.1 have known vulnerabilities and are deprecated by all major browsers. SSL 2.0 and 3.0 must never be enabled. For Nginx, set ssl_protocols to TLSv1.2 TLSv1.3 in your server block. For Apache, set SSLProtocol to all minus SSLv2 minus SSLv3 minus TLSv1 minus TLSv1.1. For IIS, disable older protocols through the Windows Registry under HKLM SYSTEM CurrentControlSet Control SecurityProviders SCHANNEL Protocols by creating DisabledByDefault and Enabled DWORD values. After changing protocol settings, restart the web server and test with SSL Labs to confirm only TLS 1.2 and 1.3 are offered. If you have legacy clients that require TLS 1.0, document the business justification and set a migration timeline rather than leaving weak protocols enabled indefinitely.
Select strong cipher suites
Cipher suites determine the encryption algorithms used for each TLS connection. Prioritize cipher suites that provide forward secrecy using ECDHE key exchange, authenticated encryption using AES-GCM or ChaCha20-Poly1305, and SHA-256 or SHA-384 for hashing. Disable cipher suites using RC4, DES, 3DES, MD5, or static RSA key exchange. For Nginx, set ssl_ciphers to a curated list and enable ssl_prefer_server_ciphers to enforce your preferred order. A recommended configuration is ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384. For TLS 1.3, cipher suites are fixed in the protocol and do not need manual configuration. Use the Mozilla SSL Configuration Generator at ssl-config.mozilla.org to generate recommended configurations for your specific server software and version.
Enable HSTS and configure security headers
HTTP Strict Transport Security tells browsers to always use HTTPS for your domain, preventing protocol downgrade attacks and cookie hijacking. Add the Strict-Transport-Security header with a max-age of at least thirty-one million five hundred thirty-six thousand seconds, which is one year. Include the includeSubDomains directive to cover all subdomains. Only add the preload directive after thorough testing, as it submits your domain to browser preload lists and is difficult to undo. For Nginx, add the header in your server block with add_header Strict-Transport-Security followed by the value. Also configure a permanent redirect from HTTP to HTTPS by creating a separate server block on port 80 that returns a 301 redirect to the HTTPS URL. Test the redirect to ensure all HTTP traffic is properly redirected before enabling HSTS.
Set up automatic certificate renewal
TLS certificates expire, and an expired certificate causes browser security warnings that block visitors. Let us Encrypt certificates are valid for ninety days and must be renewed regularly. Certbot installs a systemd timer or cron job that automatically renews certificates before expiration. Verify the renewal process works by running certbot renew with the dry-run flag. For commercial certificates with longer validity periods, set calendar reminders thirty days before expiration. Monitor certificate expiration dates using a service like Uptime Robot, Pingdom, or your Cyber Defense Score scan. Configure your web server to reload its configuration after renewal so the new certificate is served immediately. For high-availability environments, automate the certificate deployment across all servers in your cluster to prevent serving a mix of old and new certificates.
Validate your configuration with external testing tools
After completing your TLS configuration, validate it using the Qualys SSL Labs Server Test at ssllabs.com/ssltest. Enter your domain and review the detailed results. Aim for an A or A-plus rating. The test checks your certificate chain, protocol support, cipher suite configuration, and vulnerability to known attacks like BEAST, POODLE, Heartbleed, and ROBOT. Fix any issues flagged by the test. Common issues include incomplete certificate chains, weak Diffie-Hellman parameters, and missing HSTS headers. Run the test again after each fix to confirm the issue is resolved. Also test from multiple geographic locations since some CDNs and load balancers may serve different configurations from different regions. Save the test results as a baseline and re-test monthly or after any server configuration changes.
Common Mistakes to Avoid
Leaving TLS 1.0 and 1.1 enabled, which exposes the server to known protocol vulnerabilities
Missing intermediate certificates in the chain, causing trust failures on mobile devices and some browsers
Not setting up automatic certificate renewal, leading to expired certificates and site outages
Enabling HSTS preload before thoroughly testing HTTPS on all subdomains, which is difficult to reverse
Using weak cipher suites like RC4 or 3DES that provide inadequate encryption strength
Get your Cyber Defense Score™ in 60 seconds.
100 tools. No installation. No credit card.
Get My Cyber Defense Score™ →