More study resources

About this exam

The eMAPT page on INE's site currently returns a 404 and redirects to the INE homepage, so no verified statement of the credential's scope, format, length, passing score, fee, retake policy, or validity period is available. The only substantive material the retrieved page carries is a technical write-up filed under the category "PKI / TLS / applied cryptography," which is the single domain reflected in this profile. That write-up is a walkthrough of the INE Skill Dive lab "GhostTrust: Certificate Forgery and TLS Trust Abuse," built around the October 2026 eMudhra incident in which eight intermediate CA private keys were recoverable because their P-384 private scalars came from a catastrophically small candidate space. Candidates preparing in this domain should be able to explain the chain of trust from root to intermediate to leaf, why a mathematically valid signature can still represent a forged identity, how low-entropy key generation collapses the discrete-log assumption, and why a stale trust bundle in non-browser software outlives browser blocklists. Practical preparation means working hands-on with certificate inspection, key recovery against deliberately weak keys, unauthorized leaf issuance, and comparing legacy versus patched trust policies. Treat every administrative detail as unconfirmed until INE publishes a working certification page. This page is independent study material and is not affiliated with or endorsed by INE.

What you'll study

Common questions

About eMAPT preparation

Is the eMAPT exam page working right now?

No. The certification URL returns a 404 and redirects to the INE homepage, so format, length, price, and scoring are not published there as of the retrieval date. Do not rely on secondhand figures from older blog posts or forum threads. Confirm details directly with INE before booking.

What topic area does this profile attribute to the exam?

Only one domain is recorded: PKI, TLS, and applied cryptography. That comes from the category label on the sole technical article the retrieved page carries. It is the single verified signal about subject matter, not a published exam blueprint or weighting.

What is the core idea behind the GhostTrust lab?

A client can report a valid TLS chain while talking to an attacker. The lab has a bank connector accept an APPROVED settlement from a forged endpoint while the genuine origin returns HOLD. Encryption worked; authentication failed because the intermediate signing key was recoverable and the trust bundle was stale.

Why were the eMudhra intermediate keys recoverable?

Their P-384 private scalars came from a tiny candidate set, reportedly below 256, so anyone could derive dG for each candidate and compare against the public point published in the certificate. The curve was not broken and the root keys were not compromised; the key generation simply never supplied the expected entropy.

Does holding an intermediate CA key let someone decrypt old traffic?

No. An intermediate signing key enables issuing new certificates; it is not a session secret or a server's historical leaf private key. Possession does not passively decrypt recorded sessions, recover historical plaintext, or place an attacker on the network path. Impersonation still needs an active adversary-in-the-middle position.

Which clients were hardest to remediate?

Non-browser software: command-line tools, containers, language runtimes, embedded devices, proxies, and applications carrying their own CA bundle or skipping Certificate Transparency enforcement. Chrome's CRLSet block and CT enforcement protected default browsers quickly; baked-in trust stores in long-lived images did not update themselves.

What practical skills should I drill first?

Certificate inspection with openssl x509 and s_client, matching a recovered private key to a certificate's public key by comparing DER-encoded SHA-256 hashes, issuing a constrained leaf from an intermediate, and running the same handshake against a legacy and a patched CA bundle to see verification succeed then fail.

What is the most common conceptual mistake?

Treating a green padlock as proof of identity. Validation only answers whether the leaf links, under current policy, to an accepted trust anchor for the requested hostname. It cannot know whether an intermediate key was generated safely. The other frequent error is assuming revocation is checked for intermediates when only leaf certificates are.

How should I sequence study if I cannot confirm the blueprint?

Start with chain-of-trust fundamentals and EC public-key math, then move to the eMudhra incident record and the GhostTrust lab, then to remediation: inventorying trust stores, comparing bundle versions, monitoring CT, and testing real application TLS paths rather than a browser alone. Re-check the INE page periodically for an official outline.