When a browser opens an HTTPS address, the web server presents an SSL certificate before the page data begins to move. Through a trusted certificate authority's signature, the certificate connects the requested hostname to a public key. This lets the browser authenticate the server and establish an encrypted connection.
That familiar name is historical. Modern web connections use Transport Layer Security, or TLS, which replaced the older Secure Sockets Layer protocols. Providers continue to sell and describe TLS server certificates as SSL certificates. During setup, the certificate supplies identity evidence, while TLS protects the traffic that follows.
A Certificate Is a Signed Identity Record
Public server certificates contain the domain names they cover and the public key associated with the server's private key. They also name the issuer and provide validity dates. Finally, the certificate authority adds a cryptographic signature that a browser can verify.
The matching private key stays on the server and must remain secret. The certificate can be distributed to every visitor because its public key does not reveal the private key. Revoke and replace the certificate after exposure of its private key. Remove the compromised key from every server configuration that used it.
Certificate authorities issue public certificates after validating a request. For a domain-validated certificate, that process establishes control of the named domain. Business practices and application code remain outside domain validation.
How one HTTPS connection begins
The exact TLS message sequence depends on the protocol version and negotiated options. A site owner needs the functional sequence, since it explains several common certificate errors.
Server Certificate Chain
The web server sends its certificate for the requested hostname. It normally provides one or more intermediate certificates as well. Those intermediate certificates connect the website certificate to a root certificate that the browser or operating system already trusts.
A missing intermediate can produce a trust warning even when the website certificate has not expired. This is why uploading one certificate file without its required chain may leave some visitors unable to connect.
Browser Identity and Trust Checks
The browser confirms that the requested hostname appears in the certificate. It checks the validity period and verifies the signatures through the intermediate chain. The chain must end at a trusted root and comply with current browser policy.
A certificate for www.example.com may not cover example.com, depending on the names included when it was issued. The browser evaluates the hostname it requested. DNS pointing both names to the same server does not extend certificate coverage.
An expired certificate fails because its signed validity period has ended. A certificate from an unknown issuer fails because the browser cannot connect the signature chain to a trusted root. These warnings describe different defects even when the browser displays a similar interruption page.
Session-Key Establishment
The browser and server use asymmetric cryptography during the TLS handshake to authenticate the exchange and establish shared key material. They then use efficient symmetric session encryption for the application traffic. Page bytes do not pass through public-key encryption one by one.
HTTP requests and responses travel inside the encrypted TLS connection after a successful handshake. The address begins with HTTPS because HTTP is being carried through that protected channel. A later connection creates new session material according to the negotiated protocol behavior.
What HTTPS protects
HTTPS protects confidentiality and integrity while data travels between the browser and the server. An observer on the network should not be able to read a submitted password or alter a page response without detection. This protection matters on an informational website too, since ordinary HTTP traffic can be modified in transit and visitors may submit data through forms added later.
What a valid certificate cannot prove
A fraudulent operator can control a lookalike domain and obtain a valid certificate for it. Issuance establishes control of the covered hostname, which is the identity the browser authenticates during the connection.
The certificate also does not patch a vulnerable plugin or remove malware from the server. It cannot correct weak passwords or excessive administrator access. An injection flaw can expose database records through requests sent inside HTTPS. Website security also depends on the application and hosting environment.
Choose validation and hostname coverage
Domain validation verifies domain control and is sufficient for most public websites. Organization Validation and Extended Validation add forms of organizational identity checking. The protocol version and negotiated cipher suite govern the connection's encryption strength.
Before choosing coverage, list every requested hostname:
- example.com
- www.example.com
- shop.example.com
Use a single-domain certificate for 1 public name. For the 2 subdomains, *.example.com may cover both; the apex usually needs explicit coverage. Multi-domain coverage can list all 3 exact names. Verify the final certificate against every hostname that visitors or integrations must reach.
Free publicly trusted domain-validated certificates can support the same current TLS protocols as paid domain-validated products. Payment may buy human support and identity vetting. A warranty or enterprise workflow may also have value in a specific procurement process. It should correspond to a named service requirement, since price alone does not alter the encryption negotiated by the browser.
Included certificates still need deployment checks
After an included certificate is activated, confirm that every required hostname is covered. Verify automatic renewal and add a working HTTP redirect. Pages must also load their important resources securely.
GreenGeeks, for example, includes free SSL with its current WordPress hosting plans. This makes a standard domain-validated certificate a hosting feature and removes a separate invoice. Customers should test the apex and www hostnames after activation. Before launch, confirm who can replace the certificate and where that control appears.
Public certificate lifetimes are becoming shorter. Certificates issued from March 15, 2026 through March 14, 2027 have a maximum validity of 200 days under current industry requirements. Manual renewal is therefore a fragile operating plan. Automation needs independent expiry monitoring so a failed renewal becomes visible before a browser warning does. Set one alert before the expected renewal attempt and another after its scheduled completion. If automation fails, verify that domain-control validation can still reach the required DNS or HTTP endpoint. Replace the certificate before current validity ends and document the cause of the automation failure.
Keep HTTPS working after activation
Redirect every ordinary HTTP request to its HTTPS version after the secure site works on all intended hostnames. Update internal links and canonical addresses. Sitemaps and integration endpoints may also contain old HTTP URLs. A single permanent redirect is preferable to a chain that passes through several address variations.
Mixed content appears when an HTTPS page requests a resource through HTTP. Browsers may upgrade some requests and block others. Images might appear while a script or embedded frame fails, leaving the page partly functional despite a valid certificate.
Test deep pages and forms, then inspect the browser console for insecure requests.
HSTS can tell browsers to use HTTPS on future visits and reduce downgrade risk. Enable it only after the site works through HTTPS across the intended hostname set. A premature HSTS policy can prevent visitors from reaching a hostname whose certificate or redirect remains defective.
Monitor the live HTTPS deployment from outside the hosting account:
- Check certificate expiry independently of the host.
- Load a representative HTTPS page and report browser-level failures.
- Verify the issuer and validity dates after every renewal.
- Confirm that HTTP redirects once, then inspect internal pages for mixed content.
- Submit a form that sends visitor data.
- Repeat the external check and record the next expected renewal window.
