TLS Glossary: SSL, Certificates, Cipher Suites, and More

TLS Glossary: SSL, Certificates, Cipher Suites, and More

Tls Security Glossary

SSLBoard reports are dense with abbreviations and technical terms. This glossary covers every concept you might encounter, organised by topic so you can link directly to the term you need.

Certificates & PKI {#certificates-and-pki}

SSL Certificate / TLS Certificate {#ssl-certificate}

A digital document that binds a public key to a domain name (and optionally an organisation). When your browser connects to example.com over HTTPS, the server presents a certificate so the browser can verify it is really talking to example.com and not an impostor. “SSL certificate” and “TLS certificate” mean the same thing — the name stuck from the older SSL protocol era.

X.509 {#x509}

The standard format for public-key certificates used on the web. Every TLS certificate you encounter is an X.509 certificate. It defines fields like Subject, Issuer, validity dates, public key, and extensions.

Certificate Authority (CA) {#ca}

An organisation trusted to issue certificates. Examples: Let’s Encrypt, DigiCert, Sectigo, Google Trust Services. Your browser and operating system ship with a list of CAs they trust. If a certificate was not signed by a trusted CA (or one of its intermediates), the browser will show a warning.

Certificate Chain {#certificate-chain}

The sequence of certificates from the server’s leaf certificate up to a trusted root CA. Typically: leaf (your domain) → intermediate (signed by the root) → root (pre-installed in browsers). If any link in the chain is missing or invalid, the connection fails.

Subject {#subject}

The entity a certificate was issued to — usually the domain name. In older certificates this was a full organisation name; modern certificates rely on the SAN field instead.

Subject Alternative Name (SAN) {#san}

A certificate extension that lists all the domain names a single certificate covers. A certificate for example.com might also include www.example.com, api.example.com, and *.staging.example.com in its SAN list. SSLBoard uses SAN data to discover adjacent domains.

Wildcard Certificate {#wildcard-certificate}

A certificate that covers all subdomains at one level using * — for example, *.example.com covers www.example.com and api.example.com but not deep.sub.example.com. Wildcard certificates simplify management but can increase blast radius if the private key is compromised.

Issuer {#issuer}

The CA that signed and issued a certificate. SSLBoard’s issuer distribution section shows which CAs you depend on — useful for spotting concentration risk (e.g., if one CA has an outage or is distrusted).

Certificate Transparency (CT) {#ct}

A public, append-only log system where CAs must record every certificate they issue. This makes it possible for anyone to audit certificate issuance and detect mis-issued or fraudulent certificates. SSLBoard uses CT logs to discover all certificates ever issued for your domains — even ones you may not know about.

CAA (Certificate Authority Authorization) {#caa}

A DNS record type that declares which CAs are allowed to issue certificates for your domain. If you set a CAA record naming only letsencrypt.org, all other CAs are contractually required to refuse issuance requests. Three property types exist:

  • issue — authorises a CA for standard certificates
  • issuewild — authorises a CA for wildcard certificates
  • iodef — specifies where the CA should report policy violations

When no CAA record exists, any CA can issue — which is the default for most domains and a significant gap.

OCSP (Online Certificate Status Protocol) {#ocsp}

A protocol for checking whether a certificate has been revoked. Instead of downloading a large revocation list, the client (or server, via OCSP stapling) queries the CA’s OCSP responder for a real-time status check. SSLBoard checks OCSP to flag revoked certificates still deployed on your servers.

Certificate Expiration {#certificate-expiration}

Every certificate has a Not After date. Once expired, browsers reject it and your visitors see a full-page security warning. Certificate lifetimes have been shrinking — from multi-year to 90 days (Let’s Encrypt) and heading toward 47 days. SSLBoard flags certificates nearing expiration and ones that have already expired but are still being served.

Client Authentication (mTLS) {#mtls}

Mutual TLS — where the server also verifies a certificate from the client. Certificates with the ClientAuth Extended Key Usage (EKU) are designed for this purpose. SSLBoard flags certificates that carry this EKU so you can distinguish between server-only and mutual-auth certificates.

Protocols & Versions {#protocols-and-versions}

SSL (Secure Sockets Layer) {#ssl}

The original protocol for encrypting web traffic, designed by Netscape in the 1990s. SSL 2.0 and SSL 3.0 are both broken and deprecated. The protocol was succeeded by TLS, but the name “SSL” persists in everyday usage (“SSL certificate”, “SSL/TLS”).

TLS (Transport Layer Security) {#tls}

The successor to SSL. TLS encrypts the connection between a client (browser) and a server so that data cannot be read or tampered with in transit. Current versions:

VersionStatus
SSLv3Broken (POODLE attack). Must be disabled.
TLS 1.0Deprecated since 2020. Vulnerable to BEAST.
TLS 1.1Deprecated since 2020. No modern security features.
TLS 1.2Acceptable when configured with strong cipher suites.
TLS 1.3Current standard. Faster handshake, no legacy cipher negotiation, forward secrecy by default.

SSLBoard’s TLS Versions section shows exactly which versions each of your endpoints still accepts.

TLS Handshake {#tls-handshake}

The initial exchange between client and server that establishes the encrypted connection. During the handshake, both sides agree on a protocol version, select a cipher suite, exchange keys, and verify the server’s certificate. TLS 1.3 simplified the handshake from two round-trips to one.

HTTPS {#https}

HTTP over TLS. When you visit https://example.com, your browser establishes a TLS connection before sending any HTTP traffic. HTTPS is now the baseline expectation for every website.

Cipher Suites & Encryption {#cipher-suites-and-encryption}

Cipher Suite {#cipher-suite}

A named combination of algorithms used during a TLS connection. A cipher suite specifies: key exchange method, authentication method, bulk encryption algorithm, and message integrity check. Example: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 means ECDHE for key exchange, RSA for authentication, AES-256-GCM for encryption, SHA-384 for integrity.

AES (Advanced Encryption Standard) {#aes}

The most widely used symmetric encryption algorithm. AES operates on 128-bit blocks and supports key sizes of 128, 192, or 256 bits. AES-128 and AES-256 are both considered secure. SSLBoard looks for AES in either GCM or CBC mode (GCM is strongly preferred).

GCM (Galois/Counter Mode) {#gcm}

An authenticated encryption mode for AES that provides both confidentiality and integrity in a single operation. AES-GCM is the preferred bulk cipher for TLS 1.2 and is mandatory in TLS 1.3. It is faster and more secure than CBC mode.

CBC (Cipher Block Chaining) {#cbc}

An older encryption mode that has been the target of multiple attacks in TLS — including BEAST, Lucky Thirteen, and various padding oracle attacks. CBC cipher suites are flagged as warnings in SSLBoard reports. While not immediately broken, they should be replaced with GCM or ChaCha20-Poly1305 alternatives.

ChaCha20-Poly1305 {#chacha20}

A modern authenticated encryption algorithm that serves as an alternative to AES-GCM. It performs well on devices without hardware AES acceleration (e.g., older mobile phones). Considered equally secure to AES-GCM.

3DES (Triple DES) {#3des}

An obsolete cipher that applies the old DES algorithm three times. Vulnerable to the SWEET32 birthday attack (CVE-2016-2183). Flagged as critical in SSLBoard reports. Must be disabled.

RC4 {#rc4}

A stream cipher with known statistical biases that allow plaintext recovery. Prohibited in TLS since RFC 7465 (2015). Flagged as critical. Must be disabled.

NULL Cipher {#null-cipher}

A “cipher” that provides no encryption at all — traffic is sent in plaintext. Exists in TLS for testing purposes but must never be enabled in production. Flagged as critical.

EXPORT Cipher {#export-cipher}

Deliberately weakened ciphers from the 1990s, when US law restricted export of strong cryptography. Key sizes are 40 or 56 bits — trivially breakable. Vulnerable to the FREAK and Logjam attacks. Flagged as critical. Must be disabled.

IDEA & SEED {#idea-and-seed}

Legacy block ciphers occasionally found in older configurations. IDEA was used in early PGP; SEED is a Korean standard. Neither is recommended for TLS today. Flagged as weak in SSLBoard reports.

MD5 {#md5}

A cryptographic hash function that has been broken since 2004. Collisions can be generated trivially. Any cipher suite or certificate using MD5 is flagged as critical.

SHA / SHA-1 {#sha1}

SHA-1 is a hash function that was deprecated for certificate signing in 2017 after practical collision attacks were demonstrated (SHAttered, 2017). When SHA-1 appears in a cipher suite name (as the HMAC), it is flagged as a warning — not immediately dangerous in that context, but it indicates a legacy suite that should be replaced.

SHA-256 / SHA-384 {#sha256}

Members of the SHA-2 family. These are the standard hash functions used in modern certificates and cipher suites. SHA-256 (256-bit output) and SHA-384 (384-bit output) are both considered secure.

Key Exchange & Forward Secrecy {#key-exchange-and-forward-secrecy}

Key Exchange {#key-exchange}

The process by which client and server agree on a shared secret without transmitting it directly. The shared secret is then used to derive the symmetric encryption keys for the session. The choice of key exchange algorithm determines whether the connection has forward secrecy.

RSA Key Exchange {#rsa-key-exchange}

The client encrypts a pre-master secret with the server’s RSA public key. If the server’s private key is ever compromised in the future, all past sessions can be decrypted. This is why RSA key exchange does not provide forward secrecy. TLS 1.3 removed RSA key exchange entirely.

Diffie-Hellman (DH) {#diffie-hellman}

A key exchange algorithm that allows two parties to derive a shared secret over an insecure channel. Both sides contribute randomness, so even if the server’s long-term key is later compromised, past sessions remain safe. This property is called forward secrecy.

ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) {#ecdhe}

The modern, efficient version of Diffie-Hellman using elliptic curves. “Ephemeral” means a new key pair is generated for every session, guaranteeing forward secrecy. ECDHE is the standard key exchange for TLS 1.2 and the basis for TLS 1.3 key exchange.

Forward Secrecy (PFS — Perfect Forward Secrecy) {#forward-secrecy}

A property where compromising the server’s long-term private key does not allow an attacker to decrypt previously recorded traffic. Achieved by using ephemeral key exchange (ECDHE or DHE). SSLBoard’s Forward Secrecy section categorises each endpoint:

  • TLS 1.3 only — forward secrecy by design (best)
  • TLS 1.3 + legacy PFS — forward secrecy on all versions (good)
  • Legacy PFS only — forward secrecy on TLS 1.2, no TLS 1.3 (acceptable)
  • No PFS — vulnerable to retrospective decryption (critical)

Key Types & Strength {#key-types-and-strength}

RSA {#rsa}

The most established public-key algorithm, based on the difficulty of factoring large numbers. RSA keys of 2048 bits or more are considered secure today. SSLBoard flags RSA keys below 2048 bits as weak. Larger keys (3072, 4096) provide more margin but are slower.

ECC (Elliptic Curve Cryptography) {#ecc}

An alternative to RSA that achieves equivalent security with much smaller keys. A 256-bit ECC key is roughly equivalent to a 3072-bit RSA key. ECC certificates are faster to verify and produce smaller TLS handshakes.

Elliptic Curves (P-256, P-384, P-521) {#elliptic-curves}

Named curves used in ECC. P-256 (also called secp256r1 or prime256v1) is the most common. P-384 and P-521 offer higher security levels but are slower. SSLBoard’s key analysis shows the distribution of curves across your endpoints.

RSA-Only Host {#rsa-only-host}

An endpoint that only serves an RSA certificate, with no ECC alternative. This means no algorithm diversity — if an RSA-specific vulnerability is discovered, there is no fallback. SSLBoard flags RSA-only hosts so you can plan dual-certificate deployment.

Key Length {#key-length}

The size of the key in bits. For RSA: 2048 is the minimum acceptable, 4096 is conservative. For ECC: 256 bits (P-256) is standard. Longer keys are more secure but slower. SSLBoard reports the key length for every certificate.

Post-Quantum Cryptography {#post-quantum-cryptography}

PQC (Post-Quantum Cryptography) {#pqc}

Cryptographic algorithms designed to resist attacks from quantum computers. Today’s key exchange algorithms (RSA, ECDHE) could be broken by a sufficiently powerful quantum computer. PQC algorithms are being standardised now so that systems can transition before that day arrives.

Quantum Threat / “Harvest Now, Decrypt Later” {#quantum-threat}

The risk that an adversary records encrypted traffic today and decrypts it in the future using a quantum computer. This is why PQC migration is urgent even though large quantum computers don’t exist yet — the data being protected may still be sensitive years from now.

MLKEM (Module-Lattice-Based Key Encapsulation Mechanism) {#mlkem}

Formerly known as Kyber, MLKEM is the NIST-standardised post-quantum key encapsulation mechanism. It is the algorithm used in hybrid key exchanges in TLS today.

Hybrid Key Exchange {#hybrid-key-exchange}

A key exchange that combines a classical algorithm (like X25519) with a post-quantum algorithm (like MLKEM768). This way, the connection is secure even if one of the two algorithms turns out to be broken. Examples you will see in SSLBoard reports:

  • X25519+MLKEM768 — X25519 (classical) combined with MLKEM768 (post-quantum)
  • P-256+MLKEM768 — P-256 ECDH (classical) combined with MLKEM768

PQC Readiness {#pqc-readiness}

SSLBoard measures what percentage of your endpoints negotiate a hybrid (post-quantum) key exchange and rates your overall readiness as low, medium, or high. Endpoints that only use classical key exchange are listed in the Non-PQC Ready table.

Web Hardening {#web-hardening}

HSTS (HTTP Strict Transport Security) {#hsts}

An HTTP response header (Strict-Transport-Security) that tells browsers to only connect to your site over HTTPS — even if the user types http://. Once a browser sees the HSTS header, it will refuse plaintext HTTP connections for the duration specified by max-age. This prevents SSL stripping attacks.

Key HSTS directives:

  • max-age — how long (in seconds) the browser should enforce HTTPS-only
  • includeSubDomains — applies the policy to all subdomains
  • preload — signals that the domain wants to be included in browsers’ built-in HSTS preload list, which enforces HTTPS from the very first visit

HSTS Preload List {#hsts-preload}

A list of domains hardcoded into browsers that must always be loaded over HTTPS. Submitting your domain to the preload list (via hstspreload.org) means browsers will never make a plaintext HTTP request to your site — not even the first one. SSLBoard reports whether your endpoints have the preload directive set.

HTTP to HTTPS Redirect {#http-redirect}

When a user or bot visits http://example.com, the server should respond with a 301 redirect to https://example.com. Without this redirect, users who type your domain without https:// will initially connect over plaintext. SSLBoard checks every hostname to verify this redirect is in place.

SSL Stripping {#ssl-stripping}

An attack where a man-in-the-middle downgrades a user’s connection from HTTPS to HTTP by intercepting the initial plaintext request before the redirect happens. HSTS and HSTS preloading are the primary defences against this attack.

Endpoints & Infrastructure {#endpoints-and-infrastructure}

Endpoint {#endpoint}

In SSLBoard, an endpoint is a unique combination of hostname + IP address + port. A single domain like www.example.com might resolve to multiple IPs (load balancers, CDN nodes, IPv4 and IPv6), each serving on port 443. Each combination is a separate endpoint that SSLBoard scans independently — because they can have different certificates, different TLS configurations, and different issues.

Host / Hostname {#hostname}

A DNS name like www.example.com or api.example.com. A single domain can have many hostnames (subdomains), and each hostname can resolve to multiple IP addresses.

Port {#port}

The TCP port number where TLS is served. Port 443 is standard for HTTPS. Other common TLS ports include 8443, 993 (IMAPS), 995 (POP3S), and 636 (LDAPS). SSLBoard scans port 443 by default and will scan non-standard ports if specified.

IPv4 / IPv6 {#ipv4-ipv6}

Two versions of the Internet Protocol. IPv4 addresses look like 93.184.216.34; IPv6 addresses look like 2606:2800:220:1:248:1893:25c8:1946. SSLBoard scans both and often finds configuration differences between them — a common source of deployment drift.

Deployment Drift {#deployment-drift}

When different endpoints for the same hostname serve different certificates or TLS configurations. This often happens when a certificate is renewed on one load balancer but not another, or when IPv6 is configured separately from IPv4. SSLBoard reveals drift by scanning every endpoint independently.

Agentless Scanning {#agentless}

SSLBoard’s approach: scanning your public endpoints from the outside, without installing any software on your servers. This means no firewall rules to change, no credentials to share, and no additional attack surface. It sees exactly what an external attacker or auditor would see.

Adjacent Domains {#adjacent-domains}

Other domain names that appear in the SAN field of certificates associated with your scanned domain. For example, if a certificate for example.com also lists example.net and partner-site.com, those are adjacent domains. This helps you discover related infrastructure and understand certificate sharing patterns.

Attacks & Vulnerabilities {#attacks-and-vulnerabilities}

POODLE (Padding Oracle On Downgraded Legacy Encryption) {#poodle}

A 2014 attack (CVE-2014-3566) against SSLv3 that exploits its use of CBC padding. Allows an attacker to decrypt individual bytes of encrypted traffic. The fix is to disable SSLv3 entirely.

BEAST (Browser Exploit Against SSL/TLS) {#beast}

A 2011 attack (CVE-2011-3389) against CBC ciphers in TLS 1.0. Exploits a predictable initialisation vector to decrypt HTTPS cookies. Mitigated by TLS 1.1+ or by using non-CBC ciphers.

Lucky Thirteen {#lucky-thirteen}

A 2013 timing attack against CBC cipher suites in TLS. Exploits subtle timing differences in MAC verification to recover plaintext. Another reason to prefer GCM over CBC.

SWEET32 {#sweet32}

A 2016 birthday attack (CVE-2016-2183) against 64-bit block ciphers like 3DES. After enough traffic (roughly 32 GB), an attacker can recover plaintext blocks. The fix is to disable 3DES.

FREAK (Factoring RSA Export Keys) {#freak}

A 2015 attack that forces a downgrade to 512-bit EXPORT-grade RSA keys, which can be factored in hours. Affects servers that still support EXPORT cipher suites.

Logjam {#logjam}

A 2015 attack similar to FREAK but targeting Diffie-Hellman key exchange. Forces a downgrade to 512-bit DH, which can be computed by a well-resourced attacker. Mitigated by disabling EXPORT ciphers and using 2048-bit or larger DH groups.

Scoring & Severity {#scoring-and-severity}

TLS Score {#tls-score}

SSLBoard’s weighted 0–100 score that summarises the overall TLS health of a scanned domain. Factored across all report categories: protocol versions, cipher strength, forward secrecy, key sizes, certificate validity, HSTS, and PQC readiness. Grades:

RangeGrade
80–100Excellent
60–79Good
40–59Fair
0–39Poor

Severity Levels {#severity-levels}

Every finding in an SSLBoard report is tagged with a severity:

  • Critical — Actively exploitable or fundamentally broken. Must fix immediately. Examples: expired certificates in use, SSLv3 enabled, NULL/EXPORT ciphers, revoked certificates.
  • Warning — Not immediately exploitable but represents a known weakness or outdated practice. Should fix soon. Examples: TLS 1.0/1.1 still enabled, CBC cipher suites, SHA-1 in cipher suites, no forward secrecy.
  • Info — Informational finding that represents a best-practice gap or future risk. Examples: missing HSTS, no PQC readiness, RSA-only hosts.

Security, Privacy & Compliance {#security-privacy-compliance}

These three concepts are related but distinct. Understanding the difference helps you frame SSLBoard findings for the right audience.

Security {#security}

Protecting systems and data from unauthorised access, modification, or disruption. TLS is a security control — it encrypts data in transit so attackers cannot read or tamper with it. SSLBoard findings about weak ciphers, deprecated protocols, and missing forward secrecy are security issues: they weaken the protection of data flowing between your users and your servers.

Privacy {#privacy}

Controlling who can access personal or sensitive information and how it is used. TLS supports privacy by ensuring that data in transit is encrypted — but privacy is broader than encryption. It includes what data you collect, who you share it with, and how long you keep it. When SSLBoard flags a missing HTTPS redirect, that is a privacy issue: a user’s first request (including cookies, URL path, and query parameters) travels in plaintext where any network observer can read it.

Compliance {#compliance}

Meeting the specific requirements set by regulations, industry standards, or contractual obligations. Common compliance frameworks that reference TLS configuration:

  • PCI DSS — Requires strong cryptography for cardholder data in transit. Prohibits SSLv3, TLS 1.0, and weak ciphers. SSLBoard reports map directly to PCI DSS requirements.
  • SOC 2 — Requires encryption of data in transit as part of the Common Criteria.
  • HIPAA — Requires safeguards for protected health information (PHI) in transit.
  • NIST SP 800-52 — US government guidelines for TLS configuration. Mandates TLS 1.2+ and approved cipher suites.

An endpoint can be secure enough for your risk tolerance but still non-compliant with a specific standard — or vice versa. SSLBoard gives you the data; your compliance team maps it to the requirements that apply to your organisation.

FIPS (Federal Information Processing Standards) {#fips}

US government standards for cryptographic modules. FIPS 140-2/140-3 defines which algorithms and implementations are approved for government use. SSLBoard checks whether your cipher suites and key exchanges are FIPS-compliant, which matters for government contractors and regulated industries.

Other Terms {#other-terms}

DNS (Domain Name System) {#dns}

The system that translates human-readable domain names (example.com) into IP addresses (93.184.216.34). SSLBoard uses DNS to discover all IP addresses for your hostnames and to look up CAA records.

FQDN (Fully Qualified Domain Name) {#fqdn}

The complete domain name including all subdomains and the top-level domain, with a trailing dot in strict notation: www.example.com.. In practice, the trailing dot is usually omitted. SSLBoard normalises all hostnames to FQDNs before scanning.

Apex Domain / Root Domain {#apex-domain}

The base domain without any subdomain prefix — example.com rather than www.example.com. CAA records are often set at the apex and inherited by subdomains.

CDN (Content Delivery Network) {#cdn}

A distributed network of servers (like Cloudflare, Akamai, or AWS CloudFront) that serve your content from locations close to the user. CDNs terminate TLS on their own edge servers, so the TLS configuration your visitors experience is the CDN’s — not your origin server’s. If your CDN supports hybrid PQC key exchange, your visitors may already be PQC-ready without changes on your side.

Load Balancer {#load-balancer}

A device or service that distributes incoming traffic across multiple servers. Load balancers typically terminate TLS, meaning each one needs the correct certificate and TLS configuration. Differences between load balancers are a common source of deployment drift.

Certificate Lifecycle Management (CLM) {#clm}

The process of discovering, provisioning, deploying, monitoring, renewing, and revoking certificates across an organisation. As certificate lifetimes shrink (toward 47 days), manual CLM becomes impossible. SSLBoard reports give you the visibility needed to manage this lifecycle — or to verify that your automation is working correctly.

Photo by Aaron Burden on Unsplash