Public/private keys, certificates, CAs, and the trust chain: The foundations PKI requires

1. Core mechanism

PKI relies on an asymmetric key pair: the private key creates signatures and the matching public key verifies them. In normal enrollment, the requester sends the public key to the CA and retains the private key. A separately configured key-archival process is an exception and may send an encrypted copy for recovery. A certificate binds public-key and identity information and is signed by a CA. AD smart-card logon, LDAPS, IPsec, and service identities depend on this model, so both validation policy and key custody matter.

Interfaces and specifications

• Private key: normally generated and retained by the requester; an explicitly configured key-archival workflow may send an encrypted copy to the CA for recovery.
• Public key: included in the certificate request and carried in the certificate’s SubjectPublicKeyInfo; it can be distributed publicly.
• CA signature: covers the DER-encoded TBSCertificate; signatureAlgorithm and signatureValue are separate fields in the outer Certificate structure.
• Issuer: identifies the issuing CA; path construction uses issuer/subject relationships and other certificate information to find supporting certificates.
• Authority Key Identifier and Subject Key Identifier: help identify issuer/key relationships when multiple CA certificates are candidates.
• Trust anchor: information supplied by the verifier’s path-validation configuration, commonly a trusted root but potentially another explicitly configured CA or peer trust.
• Revocation: CRL or OCSP status is obtained separately when required by the verifier’s application/profile policy; a certificate may advertise where to retrieve status information.

Two keys with different roles

The keys in an asymmetric pair are not interchangeable. A signature created with the private key is verified with the matching public key; deriving the private key from a sufficiently strong public key is computationally impractical.

The phrase “the certificate was stolen” often points to the wrong asset. Certificates are designed to be distributed. The sensitive asset is the matching private key and the ability to use it; in normal enrollment that key stays with its owner, although a separately configured encrypted key-archival workflow is possible.

What a certificate says—and what it does not say

An X.509 Certificate contains three top-level fields: TBSCertificate, the signature algorithm, and the signature value. TBSCertificate includes the serial number, issuer, validity, subject, SubjectPublicKeyInfo, and extensions.

The certificate records a CA-signed binding between public-key and identity information for a validity interval. By itself it does not establish that an account is still active, that the key is uncompromised, or that the identity information remains current. Verifiers apply time, usage, and—where required—revocation checks separately.

Candidate paths and trust anchors

Chain building starts with the target certificate and searches for issuer certificates that form a candidate path. Path validation uses trust-anchor information as an input and evaluates the path toward the target; implementations may differ in how they build and select candidate paths.

Trust is not an intrinsic flag in the target certificate. In Windows, a chain engine uses its configured stores and trust sources; an application can use a custom engine or trust configuration. A root in the applicable Trusted Root store is a common anchor, but a configured non-self-signed intermediate or peer-trust model is also possible.

Intermediate CA certificates can issue certificates subject to path constraints. The basicConstraints extension identifies whether a certificate is a CA and can constrain path length; key-usage and application-policy checks may further restrict its use.

Time, revocation, and operational behavior

Validity is evaluated against the time used by the verifier. Clock skew can cause a currently valid certificate to be rejected or an expired certificate to appear valid to a misconfigured verifier.

Revocation status is a separate input when the application or profile requires checking. If a CRL or OCSP source is unreachable, behavior depends on client and application policy: a verifier may reject or may continue under a soft-fail policy. This behavior must be checked in the actual environment rather than assumed from the certificate format alone.

State and data flow

1. The requester creates a public/private key pair in local or hardware-protected storage.
2. In normal enrollment, the request sends the public key and requested identity data to the CA; private-key archival is a separate, explicitly configured exception.
3. The CA evaluates the request under its policy and, if approved, determines the certificate fields.
4. The CA signs the DER-encoded TBSCertificate with its signing key; the signature fields sit outside TBSCertificate.
5. The issued certificate returns to the requester. In ordinary enrollment the private key remains with its owner; if key archival is enabled, the CA may retain an encrypted copy for recovery.
6. The verifier starts with the target certificate and locates issuer certificates to construct a candidate certification path.
7. Path validation takes configured trust-anchor information as an input and checks the path from the anchor toward the target, including signatures and name/key binding.
8. Validity periods, CA/basicConstraints, key usage, application purpose, and other applicable constraints are checked according to the verifier’s policy.
9. Revocation status is checked when required by the application/profile; handling of unavailable CRL/OCSP sources follows the verifier’s policy.

2. Exploitation

Broken trust assumption

The valuable target is not the public certificate file but access to its matching private key, a trusted CA signing capability, or an ability to alter the verifier’s configured trust anchors.

Technical prerequisites

• The attacker can access a private key or influence a trusted CA/trust configuration.
• The verifier accepts the relevant identity form for the target protocol.
• At least one applicable control, such as path constraint, key custody, trust-anchor governance, or required revocation checking, is ineffective.

Exploitation mechanism

Certificate validation combines path construction, signature and name/key checks, validity, CA and key-usage constraints, application purpose, and revocation where policy requires it. Risk arises when a signing key or trust anchor is compromised, a private key is exposed or recoverable through an uncontrolled archive, or a verifier omits a required check. No cryptographic break is assumed.

Where the weak link appears

The threat model for certificate authentication is usually not breaking the signature algorithm. Realistic paths include reading an exportable private key from a host or backup, mismanaging an explicitly configured key archive, or obtaining a trusted signer’s certificate issuance capability.

The second common issue is control over what a trusted CA will sign. Who can request or approve a certificate and which identity fields the CA issues are authorization questions, connected to the templates and enrollment permissions in lesson 11.02.

Where validation can fail

If a relying party skips the CA/basicConstraints checks, it may accept an improper path that treats an end-entity certificate as a CA. If its policy requires revocation checking but it silently continues when the status source is unavailable, a revoked certificate may remain usable under that policy.

These behaviors depend on the product, version, and application policy. Verify each control in the target environment; do not infer a particular implementation result from the certificate alone.

3. Defense & Detection

Telemetry scope

• who root and ara CA'ler this in the environment reliable acceptance ediliyor and this list who by degishtirilebiliyor?
• Private key'ler where uretiliyor, exportable mi and donanim korumasi present mi?
• Revocation source when unavailable verifier taraflar reddediyor mu, continuation mi ediyor?
• Zincirdeki ara CA sertifikalarinin period and basicConstraints restriction beklendigi like mi?
• Certificate validation errors centralized as toplaniyor mu, if absent only istemcide mi kaliyor?

Events and relevant fields

• Certificate-authentication failures can leave evidence at both the verifier/service and client; one side alone may not explain the result.
• Path-building, signature, time, purpose, revoked, and revocation-source-unavailable outcomes are different failure categories and should remain distinguishable.
• A new certificate in a Trusted Root or explicitly configured trust-anchor set can change which paths a chain engine accepts. An intermediate added only to the CA store may supply a missing issuer certificate without changing the anchor set.
• Correlate the CA database request with the issued certificate to identify the requester/request and the signed Subject/SAN/public-key fields. This does not establish where the requester’s private key is stored.
• This lesson does not claim fixed Windows Event IDs; validate the event sources against the deployed version, role, and audit policy.

Neyi to monitor anlamli

A high-value trust change is the addition or removal of a certificate in the verifier’s trusted-root or explicitly configured anchor set. Track intermediate CA-store additions separately: they can complete chain building but do not automatically make that intermediate a trust anchor.

The CA database records requests and issued certificates. Correlate those records with the issued certificate to see the requester/request, template when recorded, and signed identity/public-key fields. The certificate and CA record do not by themselves show where the private key is held.

error mesajini kok nedene chevirmek

“Certificate invalid” is not one failure state. An incomplete path, bad signature, out-of-range validity, purpose mismatch, a revoked certificate, and an unavailable revocation source are distinct outcomes.

Preserve the verifier’s specific status and policy result. If categories are collapsed, a trust or revocation problem can be confused with a clock or chain-building issue.

Detection logic · KQL

// Synthetic schema example: separate root-store additions from intermediate material used for chain building.
// Table and fields must be validated for the environment; this query has not been run.
CertificateStoreChange
| where StoreName in ("Root", "CA")
| where Operation == "Add"
| extend ChangeClass = iff(StoreName == "Root", "Root-store addition", "Intermediate CA-store addition")
| summarize Count = count(), Thumbprints = make_set(Thumbprint, 20) by Computer, Actor, ChangeClass, bin(TimeGenerated, 1h)
| where Count > 0

Query assumptions

• No dataset is available; the query has not been executed.
• Table and field names are illustrative and are not a native Windows event schema.
• Central collection of certificate-store changes is assumed. Root-store additions and intermediate CA-store additions are reported as different classes; actual trust-anchor behavior depends on the chain engine/application configuration.

False positives

• Planned root or intermediate CA rollover and certificate deployment.
• Expected certificate-store population when new machines are configured.
• Legitimate software installation adding a required issuing/intermediate certificate.

Hardening

• Protect the offline root CA and limit which administrators can change trusted-root or application-specific anchor configuration.
• Generate private keys in hardware-protected storage where appropriate; make exportability a documented exception. Govern any encrypted CA key archive with separated roles and audited recovery.
• Manage root and intermediate certificate stores centrally, but review trusted roots and chain-building intermediates as separate classes.
• Publish CRL/OCSP services with appropriate availability and explicitly choose the client behavior for unavailable status sources.
• Review each CA certificate’s validity, basicConstraints/path length, and key usage before renewal or deployment.

Read the examples

30 82 01 8c 30 82 01 56 a0 03 02 01 02 02 04 4a
1f 00 c2 30 0d 06 09 2a 86 48 86 f7 0d 01 01 0b
05 00 30 58 31 17 30 15 06 0a 09 92 26 89 93 f2
2c 64 01 19 0c 07 65 78 61 6d 70 6c 65 31 19 30
17 06 0a 09 92 26 89 93 f2 2c 64 01 19 0c 09 6f
75 74 72 65 61 73 6f 6e 31 22 30 20 06 03 55 04
03 0c 19 6f 75 74 72 65 61 73 6f 6e 2d 44 43 30
31 2d 49 53 53 55 49 4e 47 2d 43 41 30 1e 17 0d
32 36 30 31 30 31 30 30 30 30 30 30 5a 17 0d 32
37 30 31 30 31 30 30 30 30 30 30 5a 30 23 31 21
30 1f 06 03 55 04 03 0c 18 68 6f 73 74 30 31 2e
6f 75 74 72 65 61 73 6f 6e 2e 65 78 61 6d 70 6c
65 30 3c 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01
05 00 03 2b 00 30 28 02 21 00 c7 a3 1f 5b 9d 20
4e 68 a1 c3 f0 7b 55 6e 9a 4d 3b 82 f1 c6 5a d9
07 e2 4f b8 1c 3d 6e 5a 77 b1 02 03 01 00 01 a3
5d 30 5b 30 09 06 03 55 1d 13 04 02 30 00 30 0e
06 03 55 1d 0f 01 01 ff 04 04 03 02 05 a0 30 1d
06 03 55 1d 0e 04 16 04 14 3a 7f 10 c2 e4 5b 89
d1 06 6f 2b 4c 8e 3d 5a 91 7b 02 cc 41 30 1f 06
03 55 1d 23 04 18 30 16 80 14 91 b4 ce 07 25 d8
3f 6a 1e 44 08 b7 cd 52 f3 9a 6d 1e 7c 08 30 0d
06 09 2a 86 48 86 f7 0d 01 01 0b 05 00 03 21 00
5e 2d 9c 40 ab 13 7f 66 81 d4 e0 b2 c9 5a 73 f8
10 2e c6 b4 99 3a 5d 7e 2c 08 f4 1b 6a 5d 37 92

Two reality checks

Assumption: A certificate is secret; anyone who gets it can impersonate the subject.

In fact: A certificate is public data and carries the public key. Signing requires the matching private key or another authorized signing capability; copying the certificate alone does not provide either.

Assumption: If a certificate signature verifies mathematically, the certificate is trusted.

In fact: Signature verification is one part of validation. The verifier also needs an acceptable path and configured trust anchor, the correct name/key binding, valid time and applicable constraints, plus revocation checking where its policy requires it.

Sources

• RFC 5280 · Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  Section 4: Certificate and TBSCertificate fields; Sections 4.2.1.1/4.2.1.2 AKI and SKI; Section 4.2.1.9 basicConstraints; Section 6 certification path validation.
• Microsoft · Public Key Infrastructure (Windows PKI) overview
  Public/private key pairs, certificates, and CA roles; trust store and chain concepts on the Windows side.
• Microsoft · Certificate chains and certificate trust
  General explanation of chain building, the trust anchor concept, and certificate chain validation steps.
• Microsoft · Certificates and Public Keys
  Normal request carries the subject public key, not its private key; key-pair roles.
• Microsoft · CERT_CHAIN_ENGINE_CONFIG
  Windows chain-engine stores, exclusive trust, and a supported configuration that treats a non-self-signed intermediate as a trust anchor.
• Microsoft · Certificate Directory
  CA database request/issued/revoked certificate/key-archive records and distinct Root versus Intermediate CA logical-store roles.
• Microsoft · Key Recovery Server
  Optional encrypted private-key archival and authorized KRA recovery workflow.