Skip to main content

SaaS TLS configuration and certificate lifecycle guide

Secure SaaS traffic with HTTPS, modern TLS, verified server names, protected keys, monitored certificate renewal, and end-to-end TLS testing.

In this guide

How should a SaaS team configure TLS and manage certificates?

Transport Layer Security (TLS) protects data in transit, detects modification and helps a client verify the server it reached. Use HTTPS for the entire authenticated session and for APIs, prefer TLS 1.3, and support TLS 1.2 only where compatibility requires it with a reviewed configuration. Disable SSL and obsolete TLS versions. Keep certificate names correct, automate renewal and protect private keys; a valid certificate alone does not prove the application or account is safe.

Require encrypted transport for every web page and API

Redirect browser navigation from HTTP to HTTPS where appropriate and serve session cookies with the Secure attribute. API endpoints should require HTTPS rather than accepting a state-changing request over cleartext and then redirecting it. Remove mixed-content resources so an HTTP script or stylesheet cannot undermine an otherwise secure page.

Use modern protocol and cipher configuration

Prefer TLS 1.3 and retain TLS 1.2 only for supported clients with a current secure configuration. Disable SSLv2, SSLv3, TLS 1.0 and TLS 1.1, which OWASP identifies as obsolete. Keep cryptographic libraries patched and review the effective configuration at the CDN, load balancer, reverse proxy and origin rather than assuming one setting applies everywhere.

Match certificate names and control private keys

Ensure the presented certificate covers the exact public hostname in its Subject Alternative Name and chains to a trusted authority for that user base. Restrict private-key access, separate keys across trust boundaries where practical and avoid a wildcard certificate shared across unrelated systems just for convenience. Track where each certificate and key is deployed.

TLS endpoint and certificate lifecycle worksheet
Hostname / connection hopTLS versions and certificate namePrivate-key owner and storageRenewal / expiry alertConfiguration test and rollback owner
Browser to edge
Edge to application origin
Service to external provider

How do you keep TLS correct across proxies and services?

Protect each hop where sensitive traffic crosses infrastructure

TLS at a CDN or load balancer encrypts the client-to-edge hop; review whether the edge-to-origin connection is also encrypted and whether the origin verifies the expected certificate. Service-to-service calls carrying sessions or sensitive data should use well-configured TLS too. Document any termination point and the trust boundary behind it.

Automate renewal with monitored ownership

Use a managed issuance and renewal process where available, alert before expiry, and track responsible owners and dependencies. Test renewals in a representative environment and confirm load balancers, containers, origins and partner allowlists pick up the new certificate. Do not rely on a calendar reminder as the only control for production expiry.

Use HSTS after HTTPS readiness is established

After the site and relevant hostnames reliably support HTTPS, use HSTS to tell browsers to keep using encrypted transport. Add subdomain coverage only after all affected subdomains are ready; long max-age, includeSubDomains and preload decisions can make recovery from a hostname or certificate mistake difficult. HSTS complements TLS configuration and secure cookies.

How should teams test TLS and certificate operations?

Check the externally effective configuration

Test every public hostname, API, legacy endpoint and relevant partner route for protocol support, certificate name, expiry, chain and redirects. Include IPv4/IPv6, regional endpoints and any separately managed staging or admin hosts. Use approved configuration scanners as evidence, then review unusual findings against the actual application and client requirements.

Exercise renewal and key-compromise procedures

In a test environment, renew and deploy a certificate, verify all layers load it and confirm monitoring detects failures. Document how to replace a compromised key, invalidate or remove affected certificates where possible and restore service. Limit access to private keys and avoid placing them in source control, logs or container images.

Verify application behavior remains secure during transport changes

Check HTTP redirects, API rejection of cleartext requests, secure-cookie delivery, HSTS behavior and service-to-service certificate validation. Test after CDN, proxy, cloud or runtime updates because TLS settings may differ by layer. Review alerts and customer impact before broad configuration changes.

SaaS TLS and certificate questions

Is HTTPS needed on pages that do not ask for a password?

Yes. Cookies, session tokens and active page content can be exposed or changed on an unencrypted route. Use HTTPS throughout the site and API.

Should a TLS certificate include every company subdomain?

Only include hostnames the certificate must serve. Broad wildcard certificates simplify deployment but expand the impact of a stolen private key; separate trust boundaries and track key placement.