Windows 11, version 23H2 security baseline

mdeklavon : EnableCertPaddingCheck should be a REG_DWORD. MSRC's documentation should be corrected; I submitted the information below to MSRC, but so far they've decided to take no action.

Insisting that the value is a REG_SZ is the suboptimal path. I did a bunch of testing and I found that Windows does not care what the registry value type is, but it explicitly treats it like a REG_DWORD. It is far more straightforward and far less mistake-prone to treat it as a REG_DWORD than as a REG_SZ.

I found that to enable the cert padding check behavior,

• the EnableCertPaddingCheck reg value must be present (any data type)
• it must be one to four bytes in size, and
• at least one of those bytes must be non-zero.

If it is zero bytes in length or more than four bytes in length (i.e., the size of a DWORD), the behavior is not enabled.

If the type is REG_DWORD, 0 disables the behavior, and any other value enables it. This is normal and expected behavior.

If the type is REG_SZ (i.e., data is stored as zero or more Unicode characters with a trailing Unicode null-terminator – “0x00 0x00”):

• The behavior is enabled if the value is one character that isn’t null bytes. E.g., it’s enabled if you set it to the character “1” (0x31 0x00), the character “0” (0x30 0x00), or the space character (0x20 00).
• The behavior is disabled if it’s a zero-length string with a null terminator (i.e., the value is two bytes, both 0x00).
• The behavior is disabled if the string is more than one character long (would result in the size being more than four bytes). E.g., if you set it to “11” or “ 1” (leading or trailing space) the behavior is not enabled.

One would expect that setting it to the value “0” would disable the behavior, but that is not true when it’s a REG_SZ, but it is when it’s a REG_DWORD.

MSRC should have documented it as a REG_DWORD because Windows treats it like one.

SecGuide.admx treating it as a DWORD was the right thing to do.