WDAC File Rule Level: PcaCertificate#

Table of Contents#

Overview
How It Works
What “PCA” Means and Why Not the Root
Certificate Chain Anatomy
Where in the Evaluation Stack
XML Representation
PowerShell Examples
Trust Surface: The Breadth Problem
Pros and Cons
Attack Resistance Analysis
When to Use vs When to Avoid
Double-Signed File Behavior
Real-World Scenario
OS Version and Compatibility Notes
Common Mistakes and Gotchas
Summary Table

1. Overview#

The PcaCertificate rule level in Windows Defender Application Control (WDAC) trusts files based on the intermediate Certificate Authority certificate that sits between the root CA and the leaf (end-entity) signing certificate in the chain. This is the “second from top” certificate in the typical three-tier PKI hierarchy.

“PCA” in WDAC terminology refers to this intermediate CA level — it is not the root CA and not the leaf cert. Understanding what PcaCertificate trusts requires understanding the full certificate chain:

1
Root CA (e.g., DigiCert Global Root G2)
2
  └── Intermediate CA / PCA (e.g., DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021)
3
        ├── Company A leaf cert (CN=Microsoft Windows)
4
        ├── Company B leaf cert (CN=Intel Corporation)
5
        ├── Company C leaf cert (CN=Adobe Inc)
6
        └── [thousands more companies' certs]

A PcaCertificate rule trusts ALL files signed by ANY leaf cert that chains up to this intermediate CA. This is the broadest cert-based rule level available in WDAC — broader than Publisher (which filters by leaf CN), broader than LeafCertificate (which targets a specific cert instance), and broader than FilePublisher (which adds filename and version filters on top of Publisher).

Key Characteristics:

Only one certificate checked: the intermediate CA (PCA)
No leaf CN check
No filename check
No version check
No file path check
Trust is “CA-wide” — every company whose code signing cert was issued by this CA is trusted

This breadth makes PcaCertificate appropriate in very specific situations (private/internal CA, Microsoft’s own infrastructure) and inappropriate for most public CA trust scenarios.

2. How It Works#

ConfigCI’s Chain Walking Logic#

When generating a PcaCertificate rule, ConfigCI walks up the certificate chain of a signed PE file and selects a specific certificate to anchor the rule. The selection logic is:

Start at the leaf certificate (index 0)
Walk up the chain: index 1 (intermediate), index 2 (next intermediate or root)
Stop at the highest certificate in the chain that can be resolved — either locally (from the Windows certificate store) or via online OCSP/AIA requests
This “highest resolvable” cert is used as the PCA anchor

In practice for publicly trusted certificates:

The resolution typically stops at the intermediate CA (index 1 from leaf)
The actual root CA certificate is often not explicitly included in the chain provided by the file’s signature
Even when the root is available locally (in Windows’ Trusted Root Certification Authorities store), ConfigCI may stop at the intermediate

The result: for most real-world signed software, “PcaCertificate level” means the intermediate CA cert.

Identifying the PCA Certificate#

1
# Which cert will ConfigCI use for PcaCertificate level?
2
function Get-WDACPcaCertInfo {
3
    param([string]$FilePath)
4

5
    $sig = Get-AuthenticodeSignature -FilePath $FilePath
6
    if ($sig.Status -ne "Valid") {
7
        Write-Warning "Invalid signature: $($sig.Status)"
8
        return
9
    }
10

11
    $leaf = $sig.SignerCertificate
12
    $chain = [System.Security.Cryptography.X509Certificates.X509Chain]::new()
13
    $chain.ChainPolicy.RevocationMode = "NoCheck"
14
    $null = $chain.Build($leaf)
15

16
    $elements = $chain.ChainElements
17

18
    Write-Host "`n=== PcaCertificate Analysis: $([System.IO.Path]::GetFileName($FilePath)) ===" -ForegroundColor Cyan
19
    Write-Host "`nFull chain ($($elements.Count) certificates):"
20

21
    for ($i = 0; $i -lt $elements.Count; $i++) {
22
        $cert = $elements[$i].Certificate
23
        $label = switch ($i) {
24
            0 { "(Leaf — NOT used for PcaCertificate)" }
25
            { $_ -eq $elements.Count - 1 } { "(Root CA — NOT used for PcaCertificate)" }
26
            default { "★ (PCA / Intermediate — USED for PcaCertificate TBS hash)" }
27
        }
28
        Write-Host "`n  [$i] $label"
29
        Write-Host "      Subject: $($cert.Subject)"
30
        Write-Host "      Issuer:  $($cert.Issuer)"
31
    }
32

33
    Write-Host "`n[PcaCertificate Rule Would Trust]"
34
    Write-Host "All software signed by ANY cert issued by:"
35
    if ($elements.Count -ge 2) {
36
        Write-Host "  $($elements[1].Certificate.Subject)"
37
        Write-Host ""
38
        Write-Host "WARNING: This includes ALL companies using this CA!"
39
        Write-Host "  e.g., If using DigiCert intermediate, ALL DigiCert customers are trusted."
40
    }
41
}
42

43
# Example usage
44
Get-WDACPcaCertInfo -FilePath "C:\Windows\System32\ntoskrnl.exe"
45
Get-WDACPcaCertInfo -FilePath "C:\Program Files\Intel\GraphicsDriver\igfxEM.exe"

The TBS Hash#

As with all certificate-based WDAC rules, the anchor is the TBS (To-Be-Signed) hash of the chosen certificate. For PcaCertificate, this is the TBS hash of the intermediate CA certificate. This hash is stable for the lifetime of that intermediate CA certificate (typically 5-20 years), which is why PcaCertificate rules require very infrequent updates.

3. What “PCA” Means and Why Not the Root#

The Name “PCA”#

“PCA” in WDAC documentation historically stood for Partner Certificate Authority — the intermediate CA that a root CA delegates authority to for issuing end-entity certificates to software partners/vendors. Over time it became shorthand for “the intermediate CA level” in WDAC context, regardless of whether the intermediate CA is technically a “partner” of anyone.

When you see <Signer Name="Microsoft Windows Production PCA 2011"> in WDAC policy XML, the “PCA” in the name refers to this intermediate CA concept.

Why ConfigCI Stops at the Intermediate CA and Not the Root#

There are several reasons ConfigCI uses the intermediate CA rather than the root:

1. Chain Resolution Limitations

Files embed their own certificate chain in the Authenticode signature, typically including leaf + one or two intermediates. The root CA certificate is usually NOT embedded — it’s expected to be in the local Windows certificate store. When ConfigCI scans offline (no internet, no root store access) or in sandboxed environments, it may not be able to resolve the chain all the way to the root. It stops at the highest cert it can verify.

2. Root Certs Are Too Broad

A root CA like “DigiCert Global Root G2” is the trust anchor for potentially thousands of intermediate CAs, which collectively issue certificates to millions of companies. A PcaCertificate rule for the root CA would effectively trust the entire world’s signed software — useless for application control.

3. Intermediate CAs Have Manageable Scope

An intermediate CA like “Microsoft Windows Production PCA 2011” is specifically scoped to Microsoft Windows binaries. Trusting this intermediate CA is a reasonable and well-defined trust scope.

Microsoft’s Own PCA Certs#

Microsoft uses multiple intermediate CA certs, each scoped to a specific purpose:

Intermediate CA Name	Purpose
Microsoft Windows Production PCA 2011	Core Windows OS components
Microsoft Windows PCA 2010	Older Windows components
Microsoft Code Signing PCA 2011	General Microsoft software
Microsoft Code Signing PCA 2010	Older Microsoft software
Microsoft Windows Third Party Component CA 2014	Third-party drivers in Windows
Microsoft Development PCA 2014	Microsoft development tools

These are all intermediate CAs — none of them are the root. Trusting any one of them at PcaCertificate level trusts only the software Microsoft has signed with that specific CA.

4. Certificate Chain Anatomy#

1
graph TD
2
    Root["Root CA\nCN=DigiCert Global Root G2\nSelf-signed, universal trust anchor\nNot used directly in PcaCertificate rules\n(too broad — would trust everything DigiCert ever issued)"]
3

4
    PCA["Intermediate CA (PCA)\nCN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021\nIssued by Root CA, valid ~10 years\n★★ PcaCertificate anchors HERE (TBS hash)\nTrusts ALL software signed by ANY cert from this CA\nIncludes: Google, Adobe, Intel, Mozilla, and thousands more"]
5

6
    Leaf_A["Leaf Cert A\nCN=Google LLC\nIssued by PCA\n→ PcaCert rule: TRUSTED\n→ Publisher rule: only if CN=Google LLC"]
7

8
    Leaf_B["Leaf Cert B\nCN=Adobe Inc\nIssued by PCA\n→ PcaCert rule: TRUSTED\n→ Publisher rule: only if CN=Adobe Inc"]
9

10
    Leaf_C["Leaf Cert C\nCN=Intel Corporation\nIssued by PCA\n→ PcaCert rule: TRUSTED\n→ Publisher rule: only if CN=Intel Corporation"]
11

12
    Leaf_Unknown["Leaf Cert ?\nCN=Unknown Company XYZ\nAlso issued by same PCA\n→ PcaCert rule: ALSO TRUSTED ⚠\nThis is the breadth risk"]
13

14
    File_G["chrome.exe\nSigned by Google LLC cert"]
15
    File_A["photoshop.exe\nSigned by Adobe Inc cert"]
16
    File_I["igxprd64.dll\nSigned by Intel cert"]
17

18
    Root -->|"issues"| PCA
19
    PCA -->|"issues"| Leaf_A
20
    PCA -->|"issues"| Leaf_B
21
    PCA -->|"issues"| Leaf_C
22
    PCA -->|"issues"| Leaf_Unknown
23
    Leaf_A -->|"signs"| File_G
24
    Leaf_B -->|"signs"| File_A
25
    Leaf_C -->|"signs"| File_I
26

27
    style Root fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
28
    style PCA fill:#0d1f12,stroke:#1a5c2a,color:#86efac
29
    style Leaf_A fill:#162032,stroke:#1e3a5f,color:#e2e8f0
30
    style Leaf_B fill:#162032,stroke:#1e3a5f,color:#e2e8f0
31
    style Leaf_C fill:#162032,stroke:#1e3a5f,color:#e2e8f0
32
    style Leaf_Unknown fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
33
    style File_G fill:#162032,stroke:#1e3a5f,color:#e2e8f0
34
    style File_A fill:#162032,stroke:#1e3a5f,color:#e2e8f0
35
    style File_I fill:#162032,stroke:#1e3a5f,color:#e2e8f0

Trust Surface Comparison Across Levels#

1
graph LR
2
    subgraph "PcaCertificate Level"
3
        PCA_Trust["Trusts EVERYTHING\nsigned by any cert\nfrom this intermediate CA\n(thousands of companies)"]
4
    end
5
    subgraph "Publisher Level"
6
        Pub_Trust["Trusts ONLY files\nfrom company with\nspecific Leaf CN\non this intermediate CA\n(one company)"]
7
    end
8
    subgraph "LeafCertificate Level"
9
        Leaf_Trust["Trusts ONLY files\nsigned by this one\nspecific cert instance\n(one cert)"]
10
    end
11
    subgraph "FilePublisher Level"
12
        FPub_Trust["Trusts ONLY specific\nfile (name + version)\nfrom specific company\non specific CA\n(one file, one publisher)"]
13
    end
14

15
    Broad(["Broadest trust ←"]) --- PCA_Trust
16
    PCA_Trust --- Pub_Trust
17
    Pub_Trust --- Leaf_Trust
18
    Leaf_Trust --- FPub_Trust
19
    FPub_Trust --- Narrow(["→ Narrowest trust"])
20

21
    style PCA_Trust fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
22
    style Pub_Trust fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
23
    style Leaf_Trust fill:#162032,stroke:#1e3a5f,color:#e2e8f0
24
    style FPub_Trust fill:#0d1f12,stroke:#1a5c2a,color:#86efac
25
    style Broad fill:#162032,stroke:#1e3a5f,color:#e2e8f0
26
    style Narrow fill:#162032,stroke:#1e3a5f,color:#e2e8f0

5. Where in the Evaluation Stack#

1
flowchart TD
2
    Start(["File Execution Requested"])
3
    HasSig{"Valid Authenticode\nsignature present?"}
4
    NoSig["Unsigned file"]
5
    HashCheck{"Hash rule\nmatch?"}
6
    FPCheck{"FilePublisher check\n(most specific cert level)"}
7
    PubCheck{"Publisher check\n(PCA TBS + Leaf CN)"}
8
    LeafCheck{"LeafCertificate check\n(Leaf cert TBS hash)"}
9
    PCACheck{"PcaCertificate check\n(Intermediate CA TBS hash only)"}
10
    WinCheck{"WHQLPublisher /\nother special levels"}
11
    Allow_FP(["ALLOW via FilePublisher"])
12
    Allow_Pub(["ALLOW via Publisher"])
13
    Allow_Leaf(["ALLOW via LeafCertificate"])
14
    Allow_PCA(["ALLOW via PcaCertificate"])
15
    Allow_Hash(["ALLOW via Hash"])
16
    Block(["BLOCK — default deny"])
17

18
    Start --> HasSig
19
    HasSig -->|"Yes"| FPCheck
20
    HasSig -->|"No"| NoSig
21
    NoSig --> HashCheck
22
    HashCheck -->|"Match"| Allow_Hash
23
    HashCheck -->|"No match"| Block
24
    FPCheck -->|"Match"| Allow_FP
25
    FPCheck -->|"No match"| PubCheck
26
    PubCheck -->|"Match"| Allow_Pub
27
    PubCheck -->|"No match"| LeafCheck
28
    LeafCheck -->|"Match"| Allow_Leaf
29
    LeafCheck -->|"No match"| PCACheck
30
    PCACheck -->|"Match"| Allow_PCA
31
    PCACheck -->|"No match"| WinCheck
32
    WinCheck -->|"Other rules..."| Block
33

34
    style Start fill:#162032,stroke:#1e3a5f,color:#e2e8f0
35
    style Allow_FP fill:#0d1f12,stroke:#1a5c2a,color:#86efac
36
    style Allow_Pub fill:#0d1f12,stroke:#1a5c2a,color:#86efac
37
    style Allow_Leaf fill:#0d1f12,stroke:#1a5c2a,color:#86efac
38
    style Allow_PCA fill:#0d1f12,stroke:#1a5c2a,color:#86efac
39
    style Allow_Hash fill:#0d1f12,stroke:#1a5c2a,color:#86efac
40
    style Block fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
41
    style HasSig fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
42
    style HashCheck fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
43
    style PCACheck fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
44
    style FPCheck fill:#162032,stroke:#1e3a5f,color:#e2e8f0
45
    style PubCheck fill:#162032,stroke:#1e3a5f,color:#e2e8f0
46
    style LeafCheck fill:#162032,stroke:#1e3a5f,color:#e2e8f0
47
    style NoSig fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
48
    style WinCheck fill:#162032,stroke:#1e3a5f,color:#e2e8f0

PcaCertificate is the broadest cert-based rule level and is checked after more specific cert-based levels. The note: ConfigCI evaluates all applicable rules simultaneously — the flowchart shows logical precedence, not strict sequential evaluation order.

6. XML Representation#

PcaCertificate Rule XML#

The defining characteristic of PcaCertificate XML is:

<CertRoot Type="TBS" Value="..."/> contains the TBS hash of the intermediate CA certificate
There is no <CertPublisher> element — its absence is what makes this PcaCertificate (not Publisher)
There is no <FileAttribRef> element — that would make it FilePublisher

1
<?xml version="1.0" encoding="utf-8"?>
2
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy" PolicyType="Base Policy">
3

4
  <Signers>
5

6
    <!--
7
      PcaCertificate Rule: Microsoft Windows Production PCA 2011
8

9
      This rule trusts ALL files signed by ANY leaf cert issued by this
10
      intermediate CA. For Microsoft Windows Production PCA 2011, that means
11
      all core Windows OS components.
12

13
      For a public CA like DigiCert, this would mean THOUSANDS of companies.
14
      PcaCertificate is only appropriate for well-scoped intermediate CAs.
15
    -->
16
    <Signer ID="ID_SIGNER_MSWIN_PCA_2011" Name="Microsoft Windows Production PCA 2011">
17

18
      <!--
19
        CertRoot: TBS hash of the INTERMEDIATE CA certificate
20
        NOT the root. NOT the leaf. The intermediate CA that issued
21
        the code signing certificates for Windows components.
22

23
        This hash is stable for the lifetime of this intermediate CA
24
        (typically 10-20 years), so this rule rarely needs updating.
25
      -->
26
      <CertRoot Type="TBS" Value="4E80BE107C860A21A621E2D0831F85F701AFF1B007AEB99BBBA4B02B72D7B6A5"/>
27

28
      <!--
29
        No CertPublisher here.
30
        The ABSENCE of CertPublisher is what makes this PcaCertificate level.
31
        With CertPublisher, this would be a Publisher rule.
32
        Without CertPublisher, ConfigCI checks ONLY the PCA TBS hash.
33
        Any leaf cert issued by this CA = trusted.
34
      -->
35

36
    </Signer>
37

38
    <!--
39
      Example: Microsoft Code Signing PCA 2011
40
      For general Microsoft applications (Office, Edge, etc.)
41
    -->
42
    <Signer ID="ID_SIGNER_MS_CODESIGNING_PCA_2011" Name="Microsoft Code Signing PCA 2011">
43
      <CertRoot Type="TBS" Value="F6F717A43AD9ABDDC8CEFDDE1C505462535E7D1307E630F9544A2D14FE8BF26E"/>
44
    </Signer>
45

46
    <!--
47
      CONTRAST: What Publisher looks like for the same CA
48
      Same CertRoot TBS hash, but CertPublisher added → narrows trust to one CN
49
    -->
50
    <Signer ID="ID_SIGNER_MS_PUBLISHER" Name="Microsoft Windows Production PCA 2011">
51
      <CertRoot Type="TBS" Value="4E80BE107C860A21A621E2D0831F85F701AFF1B007AEB99BBBA4B02B72D7B6A5"/>
52
      <CertPublisher Value="Microsoft Windows"/>  <!-- This makes it Publisher level -->
53
    </Signer>
54

55
  </Signers>
56

57
  <SigningScenarios>
58

59
    <SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS" FriendlyName="Kernel Mode">
60
      <ProductSigners>
61
        <AllowedSigners>
62
          <AllowedSigner SignerID="ID_SIGNER_MSWIN_PCA_2011"/>
63
        </AllowedSigners>
64
      </ProductSigners>
65
    </SigningScenario>
66

67
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="User Mode">
68
      <ProductSigners>
69
        <AllowedSigners>
70
          <AllowedSigner SignerID="ID_SIGNER_MSWIN_PCA_2011"/>
71
          <AllowedSigner SignerID="ID_SIGNER_MS_CODESIGNING_PCA_2011"/>
72
        </AllowedSigners>
73
      </ProductSigners>
74
    </SigningScenario>
75

76
  </SigningScenarios>
77

78
</SiPolicy>

XML Element Summary for PcaCertificate#

Element	Attribute	Role
`<Signer>`	`ID`	Unique identifier for referencing
`<Signer>`	`Name`	Human-readable name (typically the intermediate CA’s CN)
`<CertRoot>`	`Type="TBS"`	Specifies TBS hash identification
`<CertRoot>`	`Value`	TBS hash of the INTERMEDIATE CA certificate
`<AllowedSigner>`	`SignerID`	References the Signer in a signing scenario
`<CertPublisher>`	—	ABSENT — its absence is what makes this PcaCertificate, not Publisher

How to Tell PcaCertificate from LeafCertificate in XML#

Both levels produce a <Signer> with only <CertRoot> and no <CertPublisher>. The XML structures are identical in form. The only difference is which certificate’s TBS hash is stored:

PcaCertificate: <CertRoot Value="..."/> contains intermediate CA TBS hash
LeafCertificate: <CertRoot Value="..."/> contains leaf cert TBS hash

You cannot determine the level from XML structure alone. The Name attribute on <Signer> is the human-readable clue — if it names an intermediate CA (e.g., “DigiCert Code Signing PCA”) it’s PcaCertificate; if it names a vendor (e.g., “Acme Software Inc”) it’s likely LeafCertificate.

7. PowerShell Examples#

Generate PcaCertificate Rules#

1
# Generate PcaCertificate rules from Windows system files
2
New-CIPolicy `
3
    -Level PcaCertificate `
4
    -ScanPath "C:\Windows\System32" `
5
    -Fallback Hash `
6
    -OutputFilePath "C:\Policies\WindowsPcaPolicy.xml"
7

8
# WARNING: Scanning C:\Windows\System32 with PcaCertificate level will produce
9
# very few rules (because many MS components share the same intermediate CAs)
10
# but those rules will be VERY broad.

Generate PcaCertificate Rule for a Specific File#

1
# Single file PcaCertificate rule
2
$rule = New-CIPolicyRule `
3
    -Level PcaCertificate `
4
    -DriverFilePath "C:\Windows\System32\ntoskrnl.exe" `
5
    -Fallback Hash
6

7
$rule | Format-List *

Inspect What PcaCertificate Rule Will Trust#

1
function Get-PcaCertTrustScope {
2
    param([string]$FilePath)
3

4
    $sig = Get-AuthenticodeSignature -FilePath $FilePath
5
    $leaf = $sig.SignerCertificate
6
    $chain = [System.Security.Cryptography.X509Certificates.X509Chain]::new()
7
    $chain.ChainPolicy.RevocationMode = "NoCheck"
8
    $null = $chain.Build($leaf)
9

10
    Write-Host "`n=== PcaCertificate Trust Scope Analysis ===" -ForegroundColor Red
11
    Write-Host "Analyzing: $FilePath" -ForegroundColor Cyan
12

13
    Write-Host "`n[FILE'S LEAF CERT — NOT what PcaCert rule uses]"
14
    Write-Host "  Subject: $($chain.ChainElements[0].Certificate.Subject)"
15

16
    if ($chain.ChainElements.Count -ge 2) {
17
        $pca = $chain.ChainElements[1].Certificate
18
        Write-Host "`n[INTERMEDIATE CA / PCA — This IS what PcaCert rule uses]" -ForegroundColor Yellow
19
        Write-Host "  Subject:    $($pca.Subject)"
20
        Write-Host "  Issuer:     $($pca.Issuer)"
21
        Write-Host "  Valid:      $($pca.NotBefore.ToShortDateString()) → $($pca.NotAfter.ToShortDateString())"
22
        Write-Host "  Thumbprint: $($pca.Thumbprint)"
23
    }
24

25
    Write-Host "`n[RISK WARNING]" -ForegroundColor Red
26
    Write-Host "A PcaCertificate rule for this file's intermediate CA would trust:"
27
    Write-Host "  - Every file signed by the leaf cert of this file's vendor"
28
    Write-Host "  - Every file signed by leaf certs of ALL OTHER companies"
29
    Write-Host "    that have obtained code signing certs from the same intermediate CA"
30
    Write-Host ""
31
    Write-Host "If this is a public CA (DigiCert, Sectigo, GlobalSign, etc.):"
32
    Write-Host "  THOUSANDS of unrelated companies' software would be trusted."
33
    Write-Host ""
34
    Write-Host "Recommendation: Use Publisher level instead to filter by company CN."
35
}
36

37
# See the scope of trust for different files
38
Get-PcaCertTrustScope -FilePath "C:\Windows\System32\ntoskrnl.exe"   # Microsoft CA — controlled
39
Get-PcaCertTrustScope -FilePath "C:\Program Files\7-Zip\7z.exe"       # DigiCert — very broad!

Creating a Policy from Internal CA Files Only#

1
# For internal/private CA use case:
2
# Generate PcaCertificate rules from internally-signed tools
3

4
# First, verify the cert is from your internal CA
5
$sig = Get-AuthenticodeSignature "C:\InternalTools\scan-tool.exe"
6
$chain = [System.Security.Cryptography.X509Certificates.X509Chain]::new()
7
$chain.ChainPolicy.RevocationMode = "NoCheck"
8
$null = $chain.Build($sig.SignerCertificate)
9

10
Write-Host "Issuer: $($chain.ChainElements[1].Certificate.Subject)"
11
# Should show: CN=YourCompany Internal Code Signing CA
12

13
# Then generate policy — appropriate if issuer is truly your internal CA
14
New-CIPolicy `
15
    -Level PcaCertificate `
16
    -ScanPath "C:\InternalTools" `
17
    -UserPEs `
18
    -OutputFilePath "C:\Policies\InternalToolsPolicy.xml"

8. Trust Surface: The Breadth Problem#

This section is critical for understanding why PcaCertificate must be used with extreme caution for publicly-trusted intermediate CAs.

Public CA Trust Surface — A Concrete Example#

Consider a PcaCertificate rule generated from a DigiCert-signed file:

1
Your intended trust: "I trust 7-Zip (by Igor Pavlov)"
2
What PcaCertificate actually trusts:
3
  Every company that has obtained a code signing cert from
4
  DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021, which includes:
5

6
  ✓ Igor Pavlov (7-Zip)
7
  ✓ Google LLC (Chrome)
8
  ✓ Adobe Inc (Acrobat)
9
  ✓ Mozilla Corporation (Firefox)
10
  ✓ Intel Corporation (drivers)
11
  ✓ Qualcomm Technologies (drivers)
12
  ✓ Valve Corporation (Steam)
13
  ✓ NVIDIA Corporation (drivers)
14
  ✓ [Thousands of other companies...]
15
  ✓ Unknown Startup LLC (what they make is unclear to you)
16
  ✓ Any future company that gets a cert from this CA

If an attacker’s company obtains a legitimate code signing certificate from the same DigiCert intermediate CA and signs malware, a PcaCertificate rule for that CA would allow the malware. The attacker’s cert was legitimately issued — just to malicious actors.

The Contrast: Private CA Trust Surface#

For an internal/private CA, the trust surface is exactly what you define:

1
Your Internal Code Signing CA
2
  → Tool A (signed by your team)
3
  → Tool B (signed by your team)
4
  → Tool C (signed by your team)
5
  [Only what your team signed — nothing else]

A PcaCertificate rule for your internal CA is entirely appropriate. You control who gets certs from it.

Trust Surface Comparison Diagram#

1
graph TD
2
    subgraph Public_CA["Public CA Scenario — PcaCertificate = DANGER"]
3
        DigiCert_PCA["DigiCert Intermediate CA\nPcaCert TBS hash"]
4
        G["Google LLC (chrome.exe)"]
5
        A["Adobe Inc (photoshop.exe)"]
6
        I["Intel Corp (igxprd64.dll)"]
7
        V["Valve Corp (steam.exe)"]
8
        Unknown["Unknown Corp (malware.exe?)\nLegitimately signed by DigiCert"]
9
        DigiCert_PCA --- G & A & I & V & Unknown
10
    end
11

12
    subgraph Private_CA["Private/Internal CA Scenario — PcaCertificate = APPROPRIATE"]
13
        Internal_PCA["YourCompany Internal CA\nPcaCert TBS hash"]
14
        T1["scan-tool.exe\n(your team signed)"]
15
        T2["deploy-agent.exe\n(your team signed)"]
16
        T3["audit-util.exe\n(your team signed)"]
17
        Internal_PCA --- T1 & T2 & T3
18
    end
19

20
    style DigiCert_PCA fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
21
    style Unknown fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
22
    style G fill:#162032,stroke:#1e3a5f,color:#e2e8f0
23
    style A fill:#162032,stroke:#1e3a5f,color:#e2e8f0
24
    style I fill:#162032,stroke:#1e3a5f,color:#e2e8f0
25
    style V fill:#162032,stroke:#1e3a5f,color:#e2e8f0
26
    style Internal_PCA fill:#0d1f12,stroke:#1a5c2a,color:#86efac
27
    style T1 fill:#0d1f12,stroke:#1a5c2a,color:#86efac
28
    style T2 fill:#0d1f12,stroke:#1a5c2a,color:#86efac
29
    style T3 fill:#0d1f12,stroke:#1a5c2a,color:#86efac

9. Pros and Cons#

Factor	Assessment
Trust scope	Very broad — covers all certs from the intermediate CA
Maintenance burden	Extremely Low — intermediate CA certs last 10-20 years
Setup complexity	Very Low — one rule covers vast software catalog
Specificity	Lowest among cert-based levels
False positive risk	Very High for public CAs
Appropriate for public CAs	Almost never — too broad
Appropriate for private CAs	Yes — controlled scope
Survives leaf cert renewal	Yes — doesn’t check leaf certs at all
Survives publisher CN changes	Yes — doesn’t check leaf CNs
Kernel driver support	Yes
User mode support	Yes

Pros#

Near-zero maintenance: Intermediate CA certs last a decade or more. Once deployed, rarely needs updating.
Complete vendor coverage: Any file the vendor signs (past, present, future) with any cert from this CA is trusted.
Simple rules: A small number of <Signer> elements can cover vast software ecosystems.
Perfect for internal PKI: When you control the CA, PcaCertificate maps precisely to “trust everything from my internal signing infrastructure.”
Good for Windows base policy: The default Windows base policies use PcaCertificate level for Microsoft’s own intermediate CAs.

Cons#

Dangerous for public CAs: A PcaCertificate rule for DigiCert, Sectigo, or GlobalSign trusts thousands of unrelated companies.
No granularity: You cannot use PcaCertificate to trust one vendor from a CA — you get all of them.
Attack vector: Legitimate certs obtained by malicious actors will be trusted if they use the same CA.
Not appropriate as the only rule level: Should be supplemented with more specific rules for vendor software.
Audit complexity: Hard to explain to auditors why all DigiCert-signed software is trusted.

10. Attack Resistance Analysis#

1
graph TD
2
    Attacker(["Attacker Goal:\nRun malicious code on\na system with PcaCertificate\nrules for a public CA"])
3

4
    A1["Attack 1: Drop unsigned binary"]
5
    A1R(["BLOCKED\nNo signature, default deny\nPcaCert rule requires valid signature"])
6

7
    A2["Attack 2: Self-sign binary\nwith self-generated cert"]
8
    A2R(["BLOCKED\nSelf-cert not issued by trusted CA\nPCA TBS hash won't match"])
9

10
    A3["Attack 3: Sign binary with cert\nfrom DIFFERENT public CA\n(e.g., Sectigo vs DigiCert rule)"]
11
    A3R(["BLOCKED\nDifferent CA = different PCA TBS hash\nRule won't match"])
12

13
    A4["Attack 4: Obtain LEGITIMATE cert\nfrom the SAME intermediate CA\n(e.g., company registers, buys DigiCert OV cert)\nSign malicious binary with this cert"]
14
    A4R(["⚠ ALLOWED if using PcaCertificate rule for DigiCert\nThis is the PRIMARY risk of PcaCertificate\nfor public CAs — legitimate certs from bad actors"])
15

16
    A5["Attack 5: Exploit a vulnerable\nbut CA-signed application\nAll of its binaries trusted"]
17
    A5R(["ALLOWED — signed by same CA\nSupply chain attack via trusted vendor\nNo protection against compromised signed software"])
18

19
    A6["Attack 6: DLL hijacking using\na different vendor's signed DLL\n(same CA, different company)"]
20
    A6R(["ALLOWED if loaded by a trusted process\nWDAC evaluates the DLL itself, not context\nDLL is trusted because same CA signed it"])
21

22
    Attacker --> A1 & A2 & A3 & A4 & A5 & A6
23
    A1 --> A1R
24
    A2 --> A2R
25
    A3 --> A3R
26
    A4 --> A4R
27
    A5 --> A5R
28
    A6 --> A6R
29

30
    style Attacker fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
31
    style A1 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
32
    style A2 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
33
    style A3 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
34
    style A4 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
35
    style A5 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
36
    style A6 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
37
    style A1R fill:#0d1f12,stroke:#1a5c2a,color:#86efac
38
    style A2R fill:#0d1f12,stroke:#1a5c2a,color:#86efac
39
    style A3R fill:#0d1f12,stroke:#1a5c2a,color:#86efac
40
    style A4R fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
41
    style A5R fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
42
    style A6R fill:#1a1a0d,stroke:#7a6a00,color:#fde68a

Key Risk: The “Legitimate Cert” Attack#

The most significant risk of PcaCertificate for public CAs is that an attacker can obtain a legitimate code signing certificate from the same CA. The CA verifies the attacker’s company identity (to varying degrees depending on cert type), issues a valid cert, and the attacker can sign malicious software that passes a PcaCertificate rule targeting that CA’s intermediate cert.

OV (Organization Validation) certs: Require proof of business registration. A fake/shell company could pass this.
EV (Extended Validation) certs: More rigorous vetting. Harder to obtain fraudulently, but not impossible.
Private CA certs: Not obtainable by outsiders — this is why PcaCertificate is safe for private CAs.

11. When to Use vs When to Avoid#

1
flowchart TD
2
    Q1{"Is this for a private/internal\nCA you fully control?"}
3
    Q2{"Is this for Microsoft's own\nintermediate CAs (Windows,\nOffice, etc.)?"}
4
    Q3{"Is this for a public CA\n(DigiCert, Sectigo,\nGlobalSign, etc.)?"}
5
    Q4{"Are you building a base\npolicy for Windows OS files?"}
6
    Q5{"Do you understand that\nthis trusts ALL companies\nusing this CA?"}
7

8
    UsePCA(["PcaCertificate is appropriate\nInternal CA = controlled trust"])
9
    UsePCA_Win(["PcaCertificate appropriate\nfor Microsoft infrastructure CAs\n(pre-approved, known scope)"])
10
    Caution(["Use with extreme caution\nConsider Publisher instead"])
11
    UseForBase(["Include in base policy\nfor Windows system files"])
12
    AcceptRisk(["If explicitly accepted and\ndocumented: PcaCertificate OK\nOtherwise: use Publisher"])
13
    DontUsePCA(["DO NOT use PcaCertificate\nUse Publisher or FilePublisher"])
14

15
    Q1 -->|"Yes"| UsePCA
16
    Q1 -->|"No"| Q2
17
    Q2 -->|"Yes, Windows/Office CAs"| Q4
18
    Q2 -->|"No"| Q3
19
    Q4 -->|"Yes"| UseForBase
20
    Q4 -->|"No, other apps"| Caution
21
    Q3 -->|"Yes"| Q5
22
    Q3 -->|"No"| UsePCA_Win
23
    Q5 -->|"Yes, risks accepted"| AcceptRisk
24
    Q5 -->|"No"| DontUsePCA
25

26
    style UsePCA fill:#0d1f12,stroke:#1a5c2a,color:#86efac
27
    style UsePCA_Win fill:#0d1f12,stroke:#1a5c2a,color:#86efac
28
    style UseForBase fill:#0d1f12,stroke:#1a5c2a,color:#86efac
29
    style Caution fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
30
    style AcceptRisk fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
31
    style DontUsePCA fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
32
    style Q1 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
33
    style Q2 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
34
    style Q3 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
35
    style Q4 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
36
    style Q5 fill:#162032,stroke:#1e3a5f,color:#e2e8f0

Specific Appropriate Use Cases for PcaCertificate#

Use Case	Why PcaCertificate is OK	Notes
Microsoft Windows base policies	Microsoft’s own intermediate CAs (Windows Production PCA, etc.) have known, bounded scope	These CAs only issue certs to Microsoft teams
Internal PKI — developer toolchain	You control the CA — only your tools get certs	Automate cert issuance + policy updates
Air-gapped environments with custom PKI	No public CA exposure; policy is the only trust mechanism	Must strictly control who gets internal certs
Default Windows allowlist (UMCI)	DefaultWindows_Enforced template uses PcaCertificate for Windows CAs	Supplement with Publisher for third-party
Lab/test environments	Lower security requirements; broad trust acceptable	Do not use in production

12. Double-Signed File Behavior#

When ConfigCI encounters a double-signed file at PcaCertificate level:

Each signature has its own certificate chain, each with its own intermediate CA
ConfigCI extracts the PCA TBS hash from each signature’s chain
If the two signatures use different intermediate CAs (common for SHA-1 vs SHA-256 chains), two separate <Signer> elements are created

1
<Signer ID="ID_SIGNER_DIGICERT_SHA256_PCA" Name="DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021">
2
  <CertRoot Type="TBS" Value="3F9001EA..."/>
3
</Signer>
4

5
<Signer ID="ID_SIGNER_DIGICERT_SHA1_PCA" Name="DigiCert High-Assurance Code Signing CA-1">
6
  <CertRoot Type="TBS" Value="8A4B3F2E..."/>
7
</Signer>

Trust surface implication: Dual PcaCertificate rules from a dual-signed file effectively double the trust surface — now you’re trusting all certs from TWO intermediate CAs, not one.

Benefit: If one signature chain becomes invalid (old SHA-1 CA deprecated), the other PcaCertificate rule still covers the file.

13. Real-World Scenario#

Scenario: Building a Windows base policy using Microsoft’s intermediate CAs

The most legitimate and common real-world use of PcaCertificate is for the Microsoft infrastructure CAs in a Windows base policy.

1
sequenceDiagram
2
    participant Admin as IT Admin
3
    participant PS as PowerShell ConfigCI
4
    participant WinRef as Windows Reference Image
5
    participant Policy as Policy XML
6
    participant Deploy as Deployment
7

8
    Admin->>PS: New-CIPolicy -Level PcaCertificate -FilePath C:\Windows -UserPEs
9
    PS->>WinRef: Scan Windows system files
10
    PS->>WinRef: Extract cert chains from ntoskrnl.exe, winlogon.exe, svchost.exe, etc.
11
    PS->>PS: All resolve to ~4-5 Microsoft intermediate CAs
12
    PS->>PS: Generate 4-5 PcaCertificate Signer rules
13
    PS-->>Policy: Write MinimumPolicy.xml
14

15
    Note over Policy: Policy contents:
16
    Note over Policy: Signer: Microsoft Windows Production PCA 2011
17
    Note over Policy: Signer: Microsoft Code Signing PCA 2011
18
    Note over Policy: Signer: Microsoft Windows PCA 2010 (legacy)
19
    Note over Policy: Signer: Microsoft Code Signing PCA 2010 (legacy)
20

21
    Admin->>PS: Add third-party apps via Publisher or FilePublisher
22
    PS-->>Policy: Merge third-party Publisher rules into policy
23
    Admin->>Deploy: Deploy merged policy in audit mode
24
    Deploy-->>Admin: Audit logs show what would be blocked
25
    Admin->>Deploy: Switch to enforcement after validation
26

27
    Note over Deploy: A new Windows Update ships
28
    Note over Deploy: New binaries still signed by same Microsoft intermediate CAs
29
    Deploy->>Deploy: New binaries evaluated: PCA TBS hash matches ✓
30
    Deploy-->>Deploy: ALLOWED — no policy update needed for Windows Updates
31

32
    Note over Deploy: Third-party app from DigiCert customer (not in policy)
33
    Deploy->>Deploy: New app evaluated: DigiCert PCA TBS hash
34
    Deploy->>Deploy: No PcaCertificate rule for DigiCert PCA
35
    Deploy->>Deploy: No Publisher rule for this vendor
36
    Deploy-->>Deploy: BLOCKED — expected behavior
37

38
    style Admin fill:#162032,stroke:#1e3a5f,color:#e2e8f0
39
    style PS fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
40
    style WinRef fill:#162032,stroke:#1e3a5f,color:#e2e8f0
41
    style Policy fill:#162032,stroke:#1e3a5f,color:#e2e8f0
42
    style Deploy fill:#0d1f12,stroke:#1a5c2a,color:#86efac

14. OS Version and Compatibility Notes#

Feature	Windows Version	Notes
PcaCertificate level (UMCI)	Windows 10 1507+	Available since initial WDAC release
PcaCertificate level (KMCI)	Windows 10 1507+	Kernel mode support
SHA-256 TBS hashes	Windows 10 1703+	Older versions used SHA-1 TBS
Multiple active policies	Windows 10 1903+	Allows base + supplemental policy combination
CiTool.exe deployment	Windows 11 22H2+	No-reboot policy deployment
`New-CIPolicy -Level PcaCertificate`	Windows 10 1607+	PowerShell ConfigCI module
HVCI compatibility	Windows 10 1703+	HVCI enforces KMCI rules strictly

ConfigCI Default Behavior#

When you run New-CIPolicy without specifying -Level, it defaults to Publisher level (not PcaCertificate). PcaCertificate must be explicitly requested. The default behavior suggests Microsoft’s own recommendation: Publisher and FilePublisher are the primary levels for enterprise use; PcaCertificate is more specialized.

Default Windows Policy Templates#

The C:\Windows\schemas\CodeIntegrity\ExamplePolicies\ directory (Windows 10 1903+) contains example policies. The DefaultWindows_Enforced.xml template uses PcaCertificate level for Microsoft’s intermediate CAs and illustrates the appropriate pattern: PcaCertificate for well-controlled Microsoft CAs, supplemented by more specific rules for additional trust.

15. Common Mistakes and Gotchas#

Mistake 1: Using PcaCertificate for Public CA Without Understanding Scope#

This is the most dangerous mistake. If you run New-CIPolicy -Level PcaCertificate against, say, Chrome or 7-Zip, you’ll get a PcaCertificate rule for the DigiCert intermediate CA. This rule will also allow Google Chrome, Adobe Acrobat, Intel drivers, Mozilla Firefox, and thousands of other applications that happen to use the same DigiCert CA.

Always check: Before deploying a PcaCertificate rule, verify whether the intermediate CA is private/controlled or a public CA with broad issuance.

Mistake 2: Thinking PcaCertificate is “PCA + CN” (Confusing with Publisher)#

A common source of confusion: “PCA Certificate level” sounds like it might check the PCA cert plus something else. It does not. PcaCertificate checks only the PCA/intermediate CA TBS hash. Nothing else. The CN of the leaf cert, the filename, the version — none of these are checked. Publisher is the level that adds the CN check.

Mistake 3: Using PcaCertificate in the Fallback Chain Without Realizing the Broadness#

1
# DANGEROUS — if a file fails FilePublisher and Publisher,
2
# it falls back to PcaCertificate, which is extremely broad
3
New-CIPolicy `
4
    -Level FilePublisher `
5
    -Fallback Publisher, PcaCertificate, Hash `
6
    -ScanPath "C:\SomeDirectory"

If the files in C:\SomeDirectory are signed by a public CA and some lack VERSIONINFO, they’ll generate PcaCertificate fallback rules. Suddenly your policy trusts everything from that public CA. Use -Fallback Publisher, Hash to avoid this.

Mistake 4: Not Documenting Which Files Generated Which PcaCertificate Rules#

Because PcaCertificate rules represent entire CA authorities rather than specific files or vendors, policy audits become difficult if you don’t document why each PcaCertificate rule exists. Include a FriendlyName or comment explaining the business justification.

Mistake 5: Using PcaCertificate for WHQL-Signed Drivers When WHQL Level Exists#

For WHQL (Windows Hardware Quality Labs) signed drivers, there is a dedicated WHQLPublisher and WHQLFilePublisher level that is more appropriate than PcaCertificate. WHQL-level rules scope trust specifically to Microsoft’s hardware certification program.

Mistake 6: Confusing XML Structure with LeafCertificate#

Both PcaCertificate and LeafCertificate rules produce identical XML: a <Signer> with <CertRoot> and no <CertPublisher>. The only semantic difference is which certificate’s TBS hash is stored. Always use descriptive Name attributes on <Signer> elements and maintain a certificate inventory to track which TBS hash belongs to which cert and at which level it was generated.

Mistake 7: Assuming PcaCertificate Rules Never Need Updating#

While intermediate CA certs last much longer than leaf certs (10-20 years vs 1-3 years), they do eventually expire or get replaced. Microsoft has transitioned from “PCA 2010” certs to “PCA 2011” certs and will presumably do so again. Plan for periodic reviews of PcaCertificate rules — perhaps every 3-5 years rather than every year like LeafCertificate.

16. Summary Table#

Property	Value
Rule Level Name	PcaCertificate
Certificate Anchored	Intermediate CA (PCA) — one level below root
Anchor Method	TBS hash of intermediate CA certificate (`<CertRoot Type="TBS">`)
Additional Filter	None — no CN, no filename, no version, no path
Key XML Difference from Publisher	No `<CertPublisher>` element; same `<CertRoot>` position
Key XML Difference from LeafCertificate	Same XML structure; differs in WHICH cert’s TBS hash is stored
Trust Granularity	All files signed by any cert issued by this intermediate CA
Trust Scope for Public CAs	Thousands of unrelated companies — EXTREMELY BROAD
Trust Scope for Private CAs	Only files your organization signs — APPROPRIATE
Maintenance Frequency	Very rare — intermediate CA certs last 10-20 years
Survives Leaf Cert Renewal	Yes — doesn’t check leaf certs
Survives Vendor CN Changes	Yes — doesn’t check leaf cert CNs
Survives Vendor CA Change	No — new CA = new intermediate = different TBS hash
Kernel Mode Support	Yes
User Mode Support	Yes
Appropriate For	Internal PKI, Microsoft’s own Windows CAs, base policies
Inappropriate For	Public CAs (DigiCert, Sectigo, GlobalSign) for general software
Key Risk	Legitimately-obtained cert from same public CA allows malicious software
XML Elements	`<Signer>` + `<CertRoot Type="TBS">` (NO `<CertPublisher>`)
PowerShell Parameter	`-Level PcaCertificate`
Default in New-CIPolicy	No — must be explicitly specified
Introduced	Windows 10 1507
Microsoft Guidance	Use for Windows OS base policies; avoid for third-party public CA software