Type a password into a website served over plain HTTP, and that password crosses the network as readable text that anyone along the path, on the same coffee-shop Wi-Fi or anywhere in between, can capture. The padlock in the browser's address bar is the sign that this isn't happening: the connection is encrypted, and the server proved its identity before a single byte of your data went out. As a technician, you'll be the one explaining that padlock, and more often, the scary full-page warning that appears when something behind it goes wrong.
CompTIA A+ Core 1 (220-1201) covers this in the Networking domain, where the ports and protocols objective lists HTTPS (Hypertext Transfer Protocol Secure) alongside the other secure protocols and their port numbers. The exam expects you to know port 443 versus port 80 cold, to recognize the secure variants of email protocols, and, in scenario questions, to identify why a user is seeing a certificate warning. This article covers HTTPS itself, the TLS handshake, digital certificates, and the certificate errors you'll diagnose on the job.
HTTPS is ordinary HTTP wrapped in an encrypted tunnel
HTTP, the Hypertext Transfer Protocol, is the language browsers and web servers use to request and deliver pages, and it was designed with no security at all. Everything, URLs, form data, cookies, passwords, travels in cleartext, and neither side proves who it is. That creates two distinct problems: eavesdropping, where an attacker reads the traffic, and impersonation, where an attacker pretends to be the server you meant to reach.
HTTPS solves both by running the same HTTP conversation inside a protective layer called TLS, Transport Layer Security. TLS does three jobs at once: it encrypts the traffic so intercepted data is unreadable, it authenticates the server with a digital certificate so the browser knows it reached the real site, and it protects integrity, meaning data can't be silently altered in transit.
The port number is how you tell the two apart. Plain HTTP uses TCP port 80; HTTPS uses TCP port 443, and the exam treats both as memorize-on-sight facts. In a firewall question, port 80 means unencrypted web and port 443 means encrypted web. In the real world, nearly all web traffic is HTTPS now; browsers flag plain HTTP pages as "Not secure," and many sites redirect port 80 requests straight to 443.
SSL is the old name; TLS 1.2 and 1.3 are what actually run today
You'll hear "SSL" and "TLS" used as if they were interchangeable, and it's worth untangling them once so exam questions can't trip you. SSL, Secure Sockets Layer, was the original protocol developed in the 1990s to secure web traffic, and every version of it was eventually found to have security weaknesses. The Internet Engineering Task Force (IETF) took over the work, renamed it, and published Transport Layer Security as the direct replacement.
Every version of SSL proper, along with early TLS 1.0 and 1.1, is deprecated and should be disabled. The versions in active use are TLS 1.2, still widespread and secure when configured properly, and TLS 1.3, the current standard, which is faster and drops a long list of outdated cryptographic options.
| Protocol version | Status | What to know |
|---|---|---|
| SSL 2.0 / 3.0 | Deprecated, insecure | Should be disabled on all systems |
| TLS 1.0 / 1.1 | Deprecated | Legacy only; modern browsers refuse them |
| TLS 1.2 | Current, secure | Still the compatibility baseline |
| TLS 1.3 | Current standard | Faster handshake, stronger defaults |
Despite all that, the name "SSL" refuses to die: people and vendors still say "SSL certificate" for certificates that secure TLS connections. Treat the phrase as a habit of language. For the exam, remember the direction of history: SSL came first and is dead, TLS replaced it, and the current versions are 1.2 and 1.3.
The TLS handshake sets up trust and keys before any data flows
When a browser connects to an HTTPS site, there's a short setup conversation before any web content moves. This is the TLS handshake, and it has four logical steps a technician should know.
First, negotiate. The client contacts the server and announces which TLS versions and cipher suites, the specific combinations of encryption and integrity algorithms, it supports, and the server picks the strongest option both sides share. With no acceptable version or cipher in common, the handshake fails outright, which is why an ancient client sometimes can't reach a modern server at all.
Second, authenticate. The server sends its digital certificate, which contains its public key, states who the server claims to be, and carries a signature from a certificate authority vouching for that claim. The browser checks the signature, checks that the name on the certificate matches the site it asked for, checks the validity dates, and checks that the issuer is one it trusts. If any of those checks fail, this is the moment the user gets a warning instead of a web page.
Third, exchange a session key. Public-key cryptography, the kind involving the certificate's key pair, is secure but computationally slow, so the two sides use it only briefly, to securely agree on a shared secret called a session key. That session key drives fast symmetric encryption for the rest of the connection, and the agreement happens in a way an eavesdropper can't reconstruct.
Fourth, encrypt. With the session key established, all further traffic, the actual HTTP requests and responses, flows through the encrypted tunnel.
For the exam, you need the sequence, not the message-by-message detail: negotiate capabilities, authenticate the server with a certificate, exchange a session key, then encrypt. A memory hook: the certificate's key pair opens the conversation, the session key carries it.
A digital certificate is a signed identity card with a public key inside
Since so much rides on the certificate, it's worth knowing what one actually contains. A digital certificate is a small file, following a standard format called X.509, that binds an identity to a public key and is signed by an authority that vouches for the binding. Click the padlock in any browser to inspect a real site's certificate; the fields stop being abstract quickly.
| Certificate field | What it tells you |
|---|---|
| Subject / Common Name | Who the certificate belongs to, typically the site's hostname, such as www.example.com |
| Issuer | The certificate authority that signed and issued the certificate |
| Valid from / Valid to | The window of dates during which the certificate is trustworthy |
| Public key | The server's public key, used during the handshake |
| Subject Alternative Names | Additional hostnames the certificate also covers |
| Signature | The issuer's cryptographic signature over the whole certificate |
The public key in the certificate is half of a key pair. The public half can be handed to anyone, that's the point of it, but the matching private key never leaves the server, and only its holder can complete the handshake in a way that proves ownership.