Qugstart
Journal note about protocol transition checks.

Journal

Protocol transition checks before HTTPS cutover

Operational notes on staging checks, redirect determinism, and certificate validation before narrowing to HTTPS-only service.

This note covers the checks worth running in staging before narrowing to HTTPS-only service — specifically: keeping traffic visibility high, validating redirect determinism, and confirming certificate behavior under non-browser clients before the cutover window opens.

Why staging checks fail silently

The most common failure pattern is a certificate that validates cleanly in a browser but causes silent failures for non-browser clients. Load balancers, health checks, curl scripts, and internal API calls often behave differently under HTTPS than browsers do, particularly when the certificate chain is incomplete or the SNI header is missing.

Browser testing only confirms browser behavior. Test with curl -v, with wget, and with whatever HTTP clients your application uses internally before committing to cutover.

Pre-transition checklist

Before narrowing to HTTPS-only:

  • Verify the certificate includes all intermediate chain files
  • Confirm the certificate covers all hostnames that receive traffic (apex, www, and any active subdomain variants)
  • Check that the TLS handshake completes cleanly under non-browser clients: curl -v https://yourdomain.com
  • Confirm HTTP requests redirect to HTTPS with a 301 not a 302
  • Verify that redirects land on the correct canonical hostname
  • Check that HSTS is not set too aggressively before you are confident the HTTPS stack is stable
  • Run a check on all internal API calls and webhook configurations to confirm they use HTTPS endpoints before the 301s go live

Traffic visibility during transition

Keep access logs running on both HTTP and HTTPS listeners until you are satisfied that HTTP traffic has fully transitioned. Do not disable the HTTP listener on cutover day; redirect it cleanly and monitor for any traffic that is not following the redirect.

A useful pattern: enable detailed redirect logging for 48 hours post-cutover. Watch for any sources that are not following 301s — particularly older webhook senders and monitoring tools that may have hardcoded HTTP endpoints.

Certificate edge cases

Where this gets complicated:

  • SNI mismatches when a server handles multiple virtual hosts
  • Wildcard certificates that do not cover the apex domain, or apex-only certs that do not cover www
  • Certificates that expire silently because automated renewal failed or was not configured
  • Load balancers that terminate TLS before the application sees the request, making the application believe it is receiving plain HTTP

If TLS is terminated at the load balancer, confirm your application can detect whether the original request was HTTPS using the X-Forwarded-Proto header before you rely on application-level HTTPS-only logic.

Rollback criteria

Set explicit rollback criteria before the cutover window:

  • If any health check returns a TLS error, pause and investigate before proceeding
  • If any internal service returns connection failures after the switch, revert the HTTP-to-HTTPS redirect temporarily
  • Keep the ability to re-enable the HTTP listener for at least 72 hours post-cutover