eMAPT common mistakes
eMAPT · Understand the traps and how to avoid them.
Treating a certificate chain as valid as soon as the leaf's signature verifies, without building the chain up to a trusted root and checking each issuer link.
Candidates focus on the single certificate shown and forget that trust is transitive; a leaf signed by an intermediate proves nothing unless that intermediate itself chains to an anchor in the trust store, and each signature plus validity window must hold.
What to do instead
Always walk the full path: leaf → intermediates → root, verify each signature with the issuer's public key, check every validity period, and confirm the terminal root is in the trusted store. State explicitly which link fails when a chain is rejected.
Reading the Subject and Issuer distinguished names as plain strings and concluding two certificates are the same entity from a matching CN alone.
The CN is only one RDN; the full DN includes O, OU, C and more, and matching a display name says nothing about key identity. Candidates also miss that a self-signed certificate has Subject equal to Issuer but is not automatically trusted.
What to do instead
Compare full distinguished names field by field and, more importantly, compare public keys or key identifiers (SKI/AKI) to establish identity. Verify self-signed roots against the trust store rather than assuming equivalence from name matching.
Assuming a certificate is unusable because it has expired, or usable because it has not, without checking revocation status and the purpose constraints.
Validity dates are the most visible field, so candidates stop there. They ignore that a valid-dated certificate can be revoked, and that EKU/keyUsage can forbid the very operation being attempted.
What to do instead
Check three gates in order: validity window, revocation (CRL or OCSP), and key usage/extended key usage against the intended operation. Report which gate fails; a date-valid but revoked or purpose-mismatched certificate must be rejected.
Confusing encryption with signing when choosing an operation: encrypting with a private key or verifying with a public key in the wrong direction.
Both use the same key pair, so candidates pattern-match 'private key = secret = encrypt' and lose track of the goal. The result is a signature scheme used as confidentiality or a verification that proves nothing.
What to do instead
Anchor on the goal: confidentiality means encrypt with the recipient's public key, decryption with their private key; authenticity means sign with the sender's private key, verify with their public key. Write the direction down before answering.
Treating a hash as encryption, or claiming a hash can be reversed to recover the original input.
Hashing and encryption are both 'scrambling' operations in casual language, and candidates carry that intuition into the exam instead of recalling that hashing is one-way and lossy by design.
What to do instead
Memorize the distinction: encryption is reversible with a key, hashing is a fixed-length one-way digest used for integrity. If a question asks to recover plaintext from a digest, the correct answer is that it cannot be done, not a decryption step.
Selecting a symmetric cipher mode or primitive for a task that requires public-key cryptography, or vice versa, based on key size rather than the trust problem being solved.
Candidates equate 'strong' with 'long key' and pick AES for key exchange between strangers, missing that symmetric keys require a pre-shared secret while asymmetric keys solve distribution.
What to do instead
Decide by the problem: sharing secrets with strangers or signing needs asymmetric; bulk data confidentiality needs symmetric. In hybrid designs, state that asymmetric exchanges the symmetric key and symmetric encrypts the payload.
Describing TLS as providing confidentiality only, or claiming it encrypts the entire connection including the server name and IP addresses.
The padlock metaphor and 'HTTPS is encrypted' shorthand lead candidates to overstate coverage. They forget that the handshake metadata, SNI, and IP headers may be visible, and that TLS gives integrity and authentication too.
What to do instead
Enumerate all three guarantees: confidentiality of application data, integrity via MAC/AEAD, and server authentication via the certificate. Note what remains visible (IPs, SNI absent ECH) and that client authentication is optional.
Believing a TLS handshake failure is always a certificate problem, then proposing to disable verification as the remedy.
Certificate errors are the loudest symptom, so candidates jump to them. Protocol version mismatch, cipher suite mismatch, SNI/hostname mismatch, and expired intermediates produce similar-looking failures, and disabling verification hides all of them.
What to do instead
Diagnose in layers: protocol version, then cipher suite overlap, then certificate chain and hostname, then time/clock skew. Never accept 'disable verification' as a fix; identify the specific negotiation or validation step that failed.
Ignoring hostname verification and treating any certificate signed by a trusted CA as acceptable for the connection.
Chain validation and identity validation feel like the same check, so candidates stop once the chain reaches a trusted root and never compare the certificate's names to the host being contacted.
What to do instead
Separate the two checks explicitly: chain-to-trusted-root, then identity match of SAN entries against the requested hostname (CN fallback is legacy). A trusted certificate for a different name must be rejected for this connection.
Assuming forward secrecy is automatic in TLS or that any modern cipher suite provides it, without checking the key exchange.
Candidates associate 'TLS 1.3' or 'strong cipher' with forward secrecy and do not trace it to the ephemeral key exchange (ECDHE/DHE). Static RSA key transport looks equally modern in a suite name.
What to do instead
Tie forward secrecy to ephemeral Diffie-Hellman: ECDHE or DHE key exchange, not static RSA. When asked, check the key-exchange component of the suite and note that TLS 1.3 mandates ephemeral key exchange while older versions allow static RSA.