LEARN. PRACTICE. GROW.Concept and mechanism
A TLS connection can validate the certificate chain yet fail identity verification for the requested service. Trust in a CA does not authorize every name; compare expected identity with the appropriate certificate identifiers. SubjectAltName is central to current TLS identity guidance. Do not fix a failure by disabling verification or changing the report to match the wrong server. Also separate encryption from password storage. For authentication, a dedicated password-hashing function with calibrated cost makes each offline guess more expensive. A distinct salt per record limits calculation reuse across accounts without needing to be treated as a secret.
Guided application
In a fictional integration, the technical contract identifies the expected API. If the certificate matches another service, determine whether the cause is a misconfigured endpoint or unsuitable issuance, then retest identity after correction. In storage, using a fast hash and one salt for the entire database facilitates comparison and guessing at scale. Adopt a suitable implementation, measure cost in the environment, and plan migration of older records. Base64 changes representation only; it adds no cryptographic resistance. A pepper, when used, has different requirements from a salt and should remain separate from the database. This lesson focuses on initial decisions; PKI management, algorithms, and complete labs need deeper study.
A valid chain is insufficient for the requested name; a unique salt does not replace a suitable password function.
Common pitfalls
CA as any identity; time validity as name; Base64 as protection; shared salt as equivalent to unique salts.
Related topics: Scope, authorization, and risk reporting · Reconnaissance and observation limits · Systems, vulnerabilities, and evidence
Associate each mechanism with the property it actually establishes.
Reference: TLS service identity · CEH 312-50, Exam Blueprint v5.0 effective2024-04-10; Candidate Handbook v7.3 (2026-09-21)