SSL Certificates

Historically the Common Name (CN) inside the Subject distinguished name carried the hostname. Modern browsers match Subject Alternative Names (SAN) — a list of DNS names (and sometimes IP addresses) the certificate is valid for. If you visit www.example.com, the client looks for that exact name, or a permitted wildcard like *.example.com (wildcards have rules: they do not silently cover example.com itself in every policy, and they do not cover arbitrary nested labels the way beginners hope). A cert for evil-login.net does not cover yourbank.com no matter how similar the logo is. Subject can still show an organization string on some certificates. That string is not a police background check. Domain Validation (DV) certificates prove control of the domain, not that the company is kind. When the name in the address bar does not appear in SAN (and is not a valid wildcard match), the browser must fail closed. “The page looked the same” is not a field. Clicking through a name mismatch on a site that asks for secrets is how account takeover starts. This course tells you to stop, not to invent a bypass.

SAN lists are also how one certificate covers www, the apex name, and a CDN hostname. When you inspect, write every DNS SAN you see. Ask: does the name I typed appear? If you used an IP in the URL, is that IP in SAN? If not, do not invent a reason the padlock “should still count.” The handshake lesson already told you encryption without the right name is a private chat with the wrong door. Certificate fields are how the client names the door.

Issuer is the distinguished name of the CA (or intermediate) that signed this certificate. You will fully unpack CAs in the next lesson. For field reading: copy the issuer string. It should be a known public CA or an intermediate whose chain walks to a root in the device trust store — not “CN=My Laptop MITM” that appeared after you installed a random .crt from a forum. Validity is two timestamps: Not Before and Not After. Expired certificates fail. Not-yet-valid certificates fail (clocks matter: a device with the year 2018 will reject a 2025 cert). Browsers treat those failures as trust failures, not as optional cosmetics. The certificate also carries a public key (RSA or elliptic-curve) and a signature over the rest of the fields. The handshake uses that public key in CertificateVerify (TLS 1.3): the server proves it holds the matching private key. You do not need to parse ASN.1 by hand. You need to know the public key is not the AES session key, not a password, and not something you paste into Slack. Leaf private keys stay on the server. If a PEM you found includes a PRIVATE KEY block, that is a secret — toy keys only in this course, never a live production key in git or chat.

NET::ERR_CERT_COMMON_NAME_INVALID (and cousins) means the SAN list does not include the name you typed. ERR_CERT_DATE_INVALID means the clock or the dates disagree. ERR_CERT_AUTHORITY_INVALID means the chain does not land on a trusted root — the next lesson’s territory, including the disaster of installing a random root to “make the error go away.” None of those errors mean “add an exception because I am in a hurry.” On a bank, a password form, or email, you stop. You may inspect a public certificate on example.com or your own domain to learn what a healthy field set looks like. You may not teach a roommate to ignore Chrome’s interstitial so their homework loads.

openssl s_client completes a client handshake and prints the PEM. openssl x509 -noout then prints subject, issuer, dates, and the SAN extension. That is a read of a public certificate — the same bytes a browser already fetched. Target example.com or a hostname you operate. Do not aim this at a random company’s internal hostname you saw on a badge. Do not save a stolen private key. On Windows, use Git Bash or WSL if openssl is not on PATH. Then lock the notes. The next lab will repeat a similar dump into cert-lab.txt; this lesson is field vocabulary so that lab is not copy-paste without understanding.

mkdir -p "$HOME/cyberlium-lab"
cd "$HOME/cyberlium-lab"
HOST="example.com"   # or a domain YOU own

echo | openssl s_client -connect "${HOST}:443" -servername "$HOST" 2>/dev/null \
  | openssl x509 -outform PEM > "$HOME/cyberlium-lab/example-leaf.pem"

openssl x509 -in "$HOME/cyberlium-lab/example-leaf.pem" -noout \
  -subject -issuer -dates -ext subjectAltName

NOTES="$HOME/cyberlium-lab/cert-fields-notes.txt"
{
  echo "=== CERTIFICATE FIELDS ==="
  echo "host_I_typed: $HOST  (example.com OR a domain I own)"
  echo "subject:"
  echo "issuer:"
  echo "notBefore:"
  echo "notAfter:"
  echo "SAN_DNS_names:"
  echo "name_match: yes/no — does the name I typed appear in SAN?"
  echo "public_key_type: (RSA/EC — not the AES session key)"
  echo "ethics: public cert read only; no fake CA; no PRIVATE KEY from production; no click-through on banks"
} > "$NOTES"

chmod 600 "$NOTES" "$HOME/cyberlium-lab/example-leaf.pem"

You now read a certificate as a passport: names (SAN), signer (issuer), dates, public key. The pretty padlock is the result of those checks, not a substitute for them. Next — Certificate Authorities — is how issuer trust is bootstrapped, what mis-issuance looks like, why Certificate Transparency exists as a public log, and why you must not install random root CAs to silence a warning.