What is SSL/TLS?

When you open a site with https://, the browser and the server agree on a secret key before exchanging any page, password or token. Without that, everything travels as plain text: the coffee shop Wi-Fi, your internet provider and any device on the path can read and change the content. The protocol that makes this agreement is TLS.

"SSL" is still the name everyone searches for and the one hosting dashboards use, but the SSL protocol itself is retired: what runs today is TLS. Knowing how it works helps you put HTTPS on your site, bot dashboard or API, and troubleshoot when a certificate throws an error.

What is SSL/TLS?#

TLS (Transport Layer Security) is a protocol that sits between TCP and the application (HTTP, SMTP, databases and others). It gives you three guarantees:

• Confidentiality: data is encrypted, so anyone intercepting the traffic sees meaningless bytes.
• Integrity: any change along the way is detected.
• Authentication: the client uses a certificate to confirm it is talking to the server for the domain it typed.

SSL (Secure Sockets Layer) was created by Netscape in the 1990s. SSL 3.0 was prohibited by RFC 7568 because of security flaws, and TLS 1.0 and 1.1 were deprecated by RFC 8996. The versions in use today are TLS 1.2 and TLS 1.3 (RFC 8446). When someone says "SSL certificate", they almost always mean the certificate TLS uses.

How does the TLS handshake work?#

The handshake is the negotiation that happens after the TCP connection and before application data. Simplified, in TLS 1.3:

1. ClientHello. The browser sends the versions and cipher suites it supports, the domain name (the SNI extension) and its half of the key exchange.
2. ServerHello and certificate. The server picks the parameters, returns its half of the key exchange and sends the certificate, along with proof that it holds the matching private key.
3. Verification. The browser checks that the certificate is valid for the domain, has not expired and was signed by an authority it trusts.
4. Session key. Both sides compute the same symmetric key without ever sending it over the network. From then on, everything is encrypted with it.

TLS 1.3 completes this in one network round trip, one fewer than TLS 1.2, which cuts the latency of every new connection. Public-key cryptography is only used to establish the key; the data itself uses symmetric encryption, which is much faster.

What is a certificate and who signs it?#

A certificate is a file that binds a public key to a domain name. It contains the domain (or domains), the public key, the validity dates and the signature of whoever issued it.

That signature comes from a certificate authority (CA). Your operating system and browser ship with a list of trusted root CAs. In practice the server sends a chain: the site's certificate, signed by an intermediate CA, which is signed by the root. If the chain ends at a known root, the browser trusts the certificate.

Most site certificates are DV (Domain Validation): the CA only confirms that the requester controls the domain. OV and EV types also check the organization. For most projects, DV is enough, and Let's Encrypt issues this type of certificate at no cost. To compare the options, see paid vs. free SSL certificates.

Certificates have a limited lifetime, and it keeps getting shorter: Let's Encrypt, for example, has published a schedule that cuts in stages the 90 days that were its default for years. That is why renewal has to be automatic.

How do you check a domain's certificate?#

From the terminal, with OpenSSL:

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

The output shows who it was issued to (subject), who issued it (issuer) and the validity period (notBefore and notAfter). The -servername option sends the SNI, which is required when several domains share one IP.

With curl you can see the negotiated TLS version:

curl -vI https://example.com 2>&1 | grep -E "SSL connection|TLSv|expire date|issuer"

If something fails, the error message usually points the way. For the most common cases, see SSL certificate errors.

Where does TLS end in your architecture?#

Your app does not always handle TLS itself. It is common for a reverse proxy, a load balancer or a CDN to receive the HTTPS connection, decrypt the traffic there (called TLS termination) and forward the request to your app. That keeps certificates and keys out of your code.

In practice, your app may receive plain HTTP behind the proxy. To know whether the original request was HTTPS, read the X-Forwarded-Proto header (using your framework's trusted-proxy setting) instead of inferring it from the local connection's scheme.

When is TLS not enough?#

TLS protects data in transit and nothing more. It does not stop SQL injection, validate what users send, protect stored passwords or guarantee the site owner is honest. It also does not hide everything: the server IP and, in most cases, the domain name being accessed are still visible to someone watching the network.

How to do this on Square Cloud#

On Square Cloud, TLS sits in front of your application, as in the architecture from the previous section: the app listens over HTTP, on 0.0.0.0 at the port in the PORT variable, and the platform publishes the traffic over HTTPS. The certificate and private key never enter your code.

Every web application gets a *.squareweb.app subdomain with HTTPS, on every plan. The DV certificate is issued and renewed on its own, so ever-shorter validity periods never become your chore. HTTP requests are redirected to HTTPS, and the headers your application sends, such as HSTS, pass through untouched.

To use your own domain, available from the Standard plan (starting at R$44.99 per month), you create the DNS records the dashboard shows at your registrar and follow validation in real time. The certificate is issued automatically once the domain resolves. The network also includes HTTP/3, a WAF and DDoS mitigation. See the steps in custom domains and the network details in network and CDN.