From 400685ccf2212aadda5e7a72e1494b4b734eac0c Mon Sep 17 00:00:00 2001 From: Kim Klein Date: Thu, 10 Jun 2021 14:19:34 -0700 Subject: [PATCH] Added CN info to the 2nd note under table 2 Also formatted the note as lists. --- .../select-types-of-rules-to-create.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md index 7a56e31130..ace22beaca 100644 --- a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md +++ b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md @@ -109,7 +109,8 @@ Each file rule level has its benefit and disadvantage. Use Table 2 to select the > When you create WDAC policies with [New-CIPolicy](/powershell/module/configci/new-cipolicy), you can specify a primary file rule level by including the **-Level** parameter. For discovered binaries that cannot be trusted based on the primary file rule criteria, use the **-Fallback** parameter. For example, if the primary file rule level is PCACertificate but you would like to trust the unsigned applications as well, using the Hash rule level as a fallback adds the hash values of binaries that did not have a signing certificate. > [!NOTE] -> WDAC only supports signer rules for RSA certificate signing keys with a maximum of 4096 bits. +> - WDAC only supports signer rules for RSA certificate signing keys with a maximum of 4096 bits. +> - CN is what the code uses for the CertSubject and CertIssuer fields in the policy. You can use the inbox certutil to look at the underlying format and ensure UTF-8 is not being used for the CN. For example, printable string or IA5 or BMP is ok. ## Example of file rule levels in use