--- title: "What is TLS and how HTTPS works behind the padlock | StreetHosting" description: "Learn what TLS guarantees, how the TLS 1.3 handshake works, what certificates, chains and SNI are, and how to inspect it all with openssl s_client and curl." url: "https://streethosting.com.br/en/guides/infrastructure/what-is-tls-how-https-works" type: "page" language: "en-US" --- Infrastructure · 8 min · Intermediate Published on Nov 13, 2026 · Updated on Nov 13, 2026 # TLS and HTTPS in practice: handshake, certificates and how to diagnose errors The browser padlock hides a conversation of a few milliseconds between client and server. Knowing each step helps you understand why a certificate gets rejected and find the cause with two lines of commands. By [Equipe StreetHosting](https://streethosting.com.br/en/autores#equipe-streethosting) · StreetHosting infrastructure and support team [Certificates and HTTPS](https://streethosting.com.br/en/guides/topics/ssl) Summarize with: [](https://chat.openai.com/?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fwhat-is-tls-how-https-works.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "ChatGPT") [](https://claude.ai/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fwhat-is-tls-how-https-works.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Claude") [](https://www.google.com/search?udm=50&aep=11&q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fwhat-is-tls-how-https-works.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Google AI Mode") [](https://x.com/i/grok?text=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fwhat-is-tls-how-https-works.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Grok") [](https://www.perplexity.ai/search/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fwhat-is-tls-how-https-works.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Perplexity") Share: [](https://x.com/intent/tweet?text=What%20is%20TLS%20and%20how%20HTTPS%20works%20behind%20the%20padlock&url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fwhat-is-tls-how-https-works "Share on X") [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fwhat-is-tls-how-https-works "Share on Facebook") [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fwhat-is-tls-how-https-works "Share on LinkedIn") [](https://wa.me/?text=What%20is%20TLS%20and%20how%20HTTPS%20works%20behind%20the%20padlock%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fwhat-is-tls-how-https-works "Share on WhatsApp") For agents: Copy as Markdown [.md](https://streethosting.com.br/en/guides/infrastructure/what-is-tls-how-https-works.md) In this guide 7 sections * [What TLS guarantees](https://streethosting.com.br/en/guides/infrastructure/what-is-tls-how-https-works#o-que-garante) * [The TLS 1.3 handshake](https://streethosting.com.br/en/guides/infrastructure/what-is-tls-how-https-works#handshake) * [Certificate, chain and authority](https://streethosting.com.br/en/guides/infrastructure/what-is-tls-how-https-works#certificado) * [SNI and several sites on one IP](https://streethosting.com.br/en/guides/infrastructure/what-is-tls-how-https-works#sni) * [How to inspect with openssl and curl](https://streethosting.com.br/en/guides/infrastructure/what-is-tls-how-https-works#inspecionar) * [Common errors](https://streethosting.com.br/en/guides/infrastructure/what-is-tls-how-https-works#erros) * [Your own web server](https://streethosting.com.br/en/guides/infrastructure/what-is-tls-how-https-works#onde-rodar) Quick answer **TLS**is the protocol that protects an HTTPS connection. It guarantees three things: confidentiality, because nobody along the way reads the data, integrity, because nobody changes the content without being noticed, and authentication, because the server proves it owns the site's name through a certificate signed by a trusted authority. To see all of it in action, run `openssl s_client -connect host:443 -servername host` or `curl -vI https://host`. ## What TLS guarantees[](https://streethosting.com.br/en/guides/infrastructure/what-is-tls-how-https-works#o-que-garante) Plain HTTP travels in the open: anyone along the path between you and the server, such as a public wireless network or an internet provider, can read and even modify the content. TLS fixes this with three guarantees. * **Confidentiality:** the data is encrypted with a key that only the two ends know. Whoever captures the traffic sees meaningless bytes. * **Integrity:** every block carries a check. If someone changes a single bit along the way, the connection detects it and closes. * **Authentication:** the server presents a certificate proving it controls that domain name. Without it, encryption would be useless, because you could be talking to an impostor over a very well encrypted channel. What TLS does not do matters too. The padlock says the channel is secure and that the name matches the certificate, not that the site is honest. And TLS protects the trip: if the server is broken into, the data is exposed inside it. Attacks on the application are a different topic, covered in [what a WAF is](https://streethosting.com.br/en/guides/infrastructure/what-is-a-waf). ## The TLS 1.3 handshake[](https://streethosting.com.br/en/guides/infrastructure/what-is-tls-how-https-works#handshake) Before exchanging any page data, client and server perform the handshake: a short conversation to agree on the rules and create a secret key. In TLS 1.3, it takes one round trip. 1. **ClientHello:** the client introduces itself. It says which versions and ciphers it accepts, which site name it wants (the SNI) and sends its half of a key exchange, usually done with elliptic curves such as X25519. 2. **ServerHello:** the server picks the cipher and answers with its half of the key exchange. At this point both sides already compute, each on its own, the same secret key, without it ever having traveled over the network. 3. **Certificate and proof:** from here on everything is already encrypted. The server sends the certificate and a signature made with its private key, which proves it is the owner of that certificate. 4. **Finished:** each side confirms that the whole handshake arrived intact. The client checks the certificate and, if all is well, the page starts loading, already encrypted. The halves of the key exchange are temporary and discarded after the connection, which is why TLS 1.3 has forward secrecy: even if the server's private key leaks tomorrow, connections recorded yesterday stay unreadable. By comparison, TLS 1.2 needed two round trips and still accepted old ciphers. Version 1.3 removed the weak ones and shortened the wait, which helps most when the [latency to the server](https://streethosting.com.br/en/guides/infrastructure/what-is-latency-and-ping) is high, since each round trip costs the ping time. ## Certificate, chain and authority[](https://streethosting.com.br/en/guides/infrastructure/what-is-tls-how-https-works#certificado) A certificate is a digital document that ties a domain name to a public key, signed by a certificate authority, the CA. It carries the name or names it covers, the validity period, the public key and the signature of whoever issued it. The browser does not know your server, but it does know a small group of root authorities, which come installed in the system or in the browser itself. Trust reaches your certificate through a chain: | Link | Who it is | Who signs it | Where it lives | | ------------------------ | --------------------------------- | ---------------- | -------------------------------- | | Root certificate | The authority itself | Itself | Installed on the client's system | | Intermediate certificate | An issuer delegated by the root | The root | Sent by the server | | Site certificate | Your domain, also called the leaf | The intermediate | Sent by the server | The server has to send the site certificate and the intermediates. The root does not need to be sent, because the client already has it. That is why the right file to configure in Nginx is `fullchain.pem`, which bundles the certificate and the intermediates, and not the certificate alone. Validity is checked on every connection, and the certificate also has to cover the name being accessed. The guide on [an SSL certificate with Let's Encrypt and Nginx on a VPS](https://streethosting.com.br/en/guides/vps/lets-encrypt-ssl-certificate-vps) shows how to issue and renew one for free, already with the right file. ## SNI and several sites on one IP[](https://streethosting.com.br/en/guides/infrastructure/what-is-tls-how-https-works#sni) A single server, with a single IP, often hosts many domains. The problem is that the handshake happens before the browser says which site it wants, which is done later, inside HTTP. How would the server know which certificate to present? The answer is SNI (Server Name Indication): a ClientHello field where the client states the name it wants. The server reads the name and picks the right certificate, just as Nginx does with each domain's `server` block. When SNI is missing, the server hands over the default certificate, which is almost never the requested site's, and the browser complains about a wrong name. SNI travels unencrypted in regular TLS 1.3, so whoever watches the network sees the site name, even without seeing the content. An extension that encrypts this field exists, ECH, but it needs support on both ends. That is why, when testing a server that hosts several sites, you always need to state the name. It is what the openssl `-servername` option does, in the next section. This scenario shows up in [Nginx as a reverse proxy on a VPS](https://streethosting.com.br/en/guides/vps/nginx-reverse-proxy-vps), where each domain has its own certificate. ## How to inspect with openssl and curl[](https://streethosting.com.br/en/guides/infrastructure/what-is-tls-how-https-works#inspecionar) `openssl s_client` performs the handshake and shows everything that happened. Replace `exemplo.com.br` with your domain: `# full connection, with the chain the server sends openssl s_client -connect exemplo.com.br:443 -servername exemplo.com.br -showcerts /dev/null \ | openssl x509 -noout -subject -issuer -dates -ext subjectAltName` The `