reveal // https in one look

https isn't magic, it's just a conversation you can eavesdrop on (legally, on your own connections)

every time you load a website with that little padlock icon, your browser and the server are having a very fast, very structured conversation before a single byte of the actual page shows up. most people never see it because the browser hides it. but you can watch the whole thing happen in your terminal with one line, and honestly it demystifies https more than any diagram ever will.

the command

openssl s_client -connect example.com:443 </dev/null 2>/dev/null | head

run that against any domain and you'll see the server's certificate chain, the tls version negotiated, and the cipher suite it agreed to use, all before your browser would've even started rendering.

breaking it down piece by piece

openssl s_client is a built in tool that acts like a bare bones tls client. it does what your browser does under the hood: connects, negotiates encryption, and shows you the certificate, minus all the ui.

-connect example.com:443 tells it where to go. port 443 is the standard port for https, so this is the same door your browser knocks on every time you visit a secure site.

</dev/null feeds it empty input. without this, s_client sits there waiting for you to type something to send to the server, which you don't need for just inspecting a handshake.

2>/dev/null throws away error output so your terminal doesn't get cluttered with warnings you don't care about right now.

| head trims the output to the first several lines, because s_client is chatty and dumps a lot. head just gives you the highlights: the connection info and the start of the certificate chain.

what you're actually looking at

near the top you'll see something like "CONNECTED" followed by a certificate chain, which is the server proving its identity using a chain of trust that ultimately links back to a certificate authority your system already trusts. you'll also see details about the protocol version, like tls 1.2 or tls 1.3, and the cipher suite, which is the specific combination of encryption algorithms both sides agreed on for this session.

if you drop the | head and instead pipe to something like openssl x509 -noout -text, you can pull the full certificate and see the issuer, the expiration date, and what domains it actually covers. this is the exact same info your browser checks in milliseconds when it decides whether to show a padlock or a warning page.

why this matters for defenders

this isn't just a party trick. this is a diagnostic tool you should have in your back pocket. if a site's cert is about to expire, misconfigured, or issued for the wrong domain, this command shows you before your users find out the hard way with a browser error. it's also how you verify that your own server isn't accidentally serving an outdated tls version or a weak cipher that a scanner would flag in an audit.

if you run any kind of server, internal tool, api, or self hosted app behind https, run this against it periodically. it takes five seconds and tells you exactly what a client sees when it connects, which is a lot more honest than assuming "it has a lock icon so it's fine."

the takeaway

https feels like a black box because we never see it work, we just trust the padlock. but the handshake is just a protocol, and protocols can be inspected. run this command against your own domains, check the expiration dates, check the cipher suites, and make sure the chain actually resolves to something trusted. understanding how the lock works is the first step to making sure it's actually locked.