Configure HTTPS with hostname checks, safe redirects and mixed-content testing

HTTPS requires more than a certificate installed somewhere on the server. The public hostname must reach the intended service, that service must present a trusted certificate for the hostname, and the application must generate secure URLs without redirect loops or mixed content. Test each layer before declaring a website ready.

Inventory the hostnames and the TLS termination point

List the apex domain, www and any application subdomains that customers actually use. Confirm their A and AAAA records and identify whether a CDN, load balancer or web server terminates the visitor connection. A valid certificate at the origin does not fix an invalid certificate at the CDN edge, and the reverse is also true.

Decide which hostname is canonical and ensure the certificate covers every hostname that needs to accept HTTPS before redirecting. A browser must complete TLS before it can read an HTTP redirect. Redirecting www to the apex therefore does not remove the need for a valid www certificate.

Verify the certificate, hostname and trust chain

openssl s_client -connect example.com:443 \
  -servername example.com -verify_hostname example.com \
  -verify_return_error </dev/null

Look for successful chain verification and investigate errors such as an expired certificate, missing intermediate or hostname mismatch. The server name supplies SNI so a shared server can choose the intended certificate. The explicit hostname check matters: establishing an encrypted connection alone does not prove that the certificate identifies the requested website.

openssl s_client -connect example.com:443 \
  -servername example.com </dev/null 2>/dev/null |
  openssl x509 -noout -subject -issuer -dates -ext subjectAltName

This second command is an inspection aid; it is not a replacement for the verified connection above. Check all relevant hostnames and public address families. If some users report errors while your test passes, compare the destination IP and certificate each path serves.

Test redirects before adding a strict browser policy

curl --silent --show-error --output /dev/null \
  --dump-header - http://example.com/
curl --silent --show-error --location --max-redirs 5 \
  --output /dev/null --write-out 'final=%{url_effective} status=%{http_code}\n' \
  http://example.com/

Check that the result uses the intended HTTPS hostname and that paths and query strings survive appropriately. Test a real nested page, a form endpoint and any application URLs that behave differently. Permanent redirects can be cached, so rehearse the policy with care before committing to long-lived behavior.

Behind a trusted proxy, the application may see an internal HTTP connection even though the visitor used HTTPS. Configure the application and proxy to interpret forwarded scheme information securely. Trusting arbitrary client-supplied forwarding headers can create incorrect URLs or security problems; repeatedly adding redirect rules rarely fixes that design issue.

Remove mixed content and verify application behavior

• Use browser developer tools to inspect insecure scripts, stylesheets, images, frames and API calls.
• Update application base URLs, asset references and supported database settings through application-aware tools.
• Check login, password reset, checkout and secure cookie behavior after changing the scheme.
• Confirm that caches and CDNs serve the updated URLs and do not retain an old insecure page.

For WordPress, use an application-aware search and replace when stored serialized data is involved, with a backup and dry run first. A raw SQL text replacement can damage serialized values. Do not solve an insecure dependency by weakening browser protections or disabling certificate verification in application clients.

Introduce HSTS only after the deployment is stable

HTTP Strict Transport Security tells browsers to use HTTPS for future visits. It is a useful policy when HTTPS is reliable, but a long max-age can make a certificate failure harder for visitors to bypass. Start with a short, reviewed duration and increase it after observing the deployment.

The includeSubDomains option commits all covered subdomains to HTTPS. Inventory mail web interfaces, old applications and delegated services before adding it. Preloading is a further commitment with its own requirements and removal delays; it should be a deliberate operational decision, not a copied default.

curl --silent --show-error --dump-header - --output /dev/null \
  https://example.com/ | grep -i '^strict-transport-security:'

Make renewal and independent monitoring part of the setup

Document which tool renews the certificate, how validation works and which service reloads the result. Test renewal through the tool or hosting panel and monitor the certificate customers receive from outside the server. A successful renewal job that updates an unused file does not protect the public endpoint.

Keep certificate private keys out of public directories, repositories and support messages. For an incident, share the hostname, public certificate details, observed IP and error text; support does not need the private key to inspect a public TLS problem.

Primary documentation

• OpenSSL TLS client reference
• curl command-line reference
• Certbot user guide
• WP-CLI search and replace