People still say “SSL certificate,” but modern web connections use Transport Layer Security (TLS). A TLS certificate helps a browser authenticate a server for a host name and establish an encrypted connection. HTTPS is HTTP carried over TLS.
Quick answer: HTTPS protects data in transit and helps verify the server identity for a domain name. A certificate does not prove the site is trustworthy, secure from malware, or legally legitimate. Keep the certificate valid, correctly configured, and matched to every hostname you serve.
What a certificate does
A website certificate binds public-key information to one or more host names under a certificate authority’s process. When a visitor opens an HTTPS URL, the browser checks whether the certificate is valid for that host, whether it is within its validity period, and whether its trust chain is acceptable. The browser and server then negotiate cryptographic settings and derive session keys for the connection.
This process helps protect confidentiality and integrity while traffic travels between the browser and the TLS endpoint. It does not encrypt data after it reaches the application, hide every network fact, stop a user from entering information into a deceptive site, or ensure the server stores data safely. Applications still need authentication, authorization, secure coding, and appropriate data handling.
Certificate validation types
Domain validation (DV) checks control of the domain under the certificate authority’s validation method. It is commonly used for websites and does not independently verify an organization’s broader identity.
Organization validation (OV) may include checks about the organization requesting the certificate. Extended validation (EV) has additional process requirements defined by the relevant ecosystem. Browser UI has changed over time; do not promise that visitors will see a special “green bar” or that one validation type guarantees a safer business.
A certificate may cover a single host, multiple specific host names, or a wildcard pattern within the authority’s rules. Review the exact names on the certificate. A wildcard that covers one label may not cover deeper subdomains.
Issuing, installing, and renewing
A certificate must be obtained from a trusted certificate authority or managed service, then installed or activated at the TLS endpoint. That endpoint may be a web host, load balancer, reverse proxy, or CDN. A site can use different certificates at different layers.
Use the provider’s current instructions. Verify the domain-control challenge, account, hostname list, private-key handling, and renewal method. Automated issuance can reduce manual work, but automation must be monitored. A failed renewal can turn a working site into a browser warning.
After installation, test the exact variants users may visit: root domain, www, application subdomains, and any alternate hostname. Check that HTTP redirects to the chosen HTTPS URL, that internal links use HTTPS, and that any proxy-to-origin connection is configured appropriately.
Common HTTPS errors
| Browser or monitoring symptom | Likely cause to investigate | Safe response |
|---|---|---|
| Certificate expired | Renewal failed, automation stopped, or old certificate remains installed | Check the issuing account and the certificate served by the actual endpoint. Renew and verify deployment. |
| Name mismatch | Certificate does not include the requested host | Issue or configure a certificate covering that exact name. Check redirects and subdomains. |
| Untrusted or incomplete chain | Missing intermediate certificate or unsupported trust path | Follow the host or CA’s chain-installation guidance and test across clients. |
| Mixed content | HTTPS page requests an HTTP resource | Replace insecure resource URLs and inspect third-party embeds. |
| Too many redirects | Conflicting HTTPS redirects at proxy, host, or application | Map the redirect chain and choose one authoritative redirect layer. |
| Connection fails only behind proxy | TLS mode or origin certificate mismatch | Confirm the CDN/proxy mode and origin certificate requirements. |
Do not tell visitors to bypass a certificate warning. For a public website, resolve the configuration issue. In a local test environment, document the exception and never enter real credentials while a connection is untrusted.
HTTPS and security misconceptions
- “A padlock proves a business is genuine.” It proves the connection meets browser certificate checks for the host; phishing sites can use HTTPS too.
- “HTTPS protects data inside my database.” It protects the network connection to a TLS endpoint. Storage and access controls are separate.
- “A certificate covers every subdomain.” Coverage depends on the names included and certificate rules.
- “Installing a certificate fixes every warning.” Mixed content, redirects, trust-chain issues, hostname errors, and application problems can remain.
- “TLS is a one-time task.” Renewals, configuration, endpoint changes, and security maintenance continue.
A practical deployment checklist
Before launch, confirm that the certificate includes the public hostname, is installed at the serving endpoint, and renews automatically or has a clear manual process. Test the full chain and expiry monitoring. Redirect to one canonical HTTPS version. Update canonical tags, sitemap entries, internal links, and API endpoints. Check forms and third-party scripts for mixed content. Ensure the application handles proxy headers safely; do not trust arbitrary client-supplied forwarding headers.
When changing hosts or CDNs, plan certificate issuance and DNS separately. Avoid removing the old certificate or origin configuration until the new path has been tested. Keep a documented owner for certificate renewal alerts.
Frequently asked questions
Is SSL still used? “SSL certificate” remains common wording, but secure modern web connections use TLS. Follow current server and provider guidance for supported protocols.
Does HTTPS improve search ranking? Search systems may treat HTTPS as a positive technical signal, but it is not a ranking guarantee. Use HTTPS primarily to protect connections and meet user expectations.
Can I use one certificate for example.com and www.example.com? Yes, if both names are covered by the certificate and the server is configured for them.
What should I do when a certificate warning appears? Do not bypass it for a public site. Check hostname, validity, chain, proxy, and installation at the endpoint.
Is a free certificate safe? Price alone does not determine security. Check that it is issued by a trusted CA, correctly configured, and renewed reliably.
For TLS protocol details, see RFC 8446. For deployment, use the current documentation from the web host, CDN, and certificate authority you actually use.