CNG, Schannel & crypto plumbing

Kerberos, NTLM, and authentication packages mentioned cryptographic operations — signing tickets, protecting exchanges — without saying where the actual cryptographic implementations live. This chapter is about that: the centralized, system-provided crypto plumbing most Windows components (and a large share of third-party software) build on rather than reinventing.

CNG: algorithms and keys as a system service

CNG (Cryptography Next Generation, exposed through the BCrypt/NCrypt API families) is the modern Windows cryptography provider model: a common interface for hashing, symmetric and asymmetric encryption, signing, and key derivation, implemented by pluggable providers rather than hardcoded into every application that needs crypto. Centralizing this matters for reasons beyond convenience:

• Correctness. Cryptographic primitives are notoriously easy to implement subtly wrong. A single, heavily-scrutinized system implementation is a much smaller attack surface than dozens of application-specific ones.
• Consistent update path. When an algorithm is deprecated or a vulnerability is found in an implementation, updating the OS-level provider fixes every application built on CNG at once, without each of them needing its own patch.
• Hardware-backed keys. CNG's key storage providers can transparently back private keys with a TPM (Trusted Platform Module) or other hardware security module, so that key material can be used for signing or decryption operations without ever being exposed in a form software alone could exfiltrate.

Schannel: TLS as a Windows security support provider

Schannel implements SSL/TLS as another SSPI-pluggable security support provider — the same framework Kerberos, NTLM, and authentication packages described Kerberos and NTLM plugging into. This is a deliberate architectural choice: rather than TLS being a separate, bolted-on feature, it's exposed through the exact same interface applications already use for other forms of authentication, which is what lets components like LDAP-over-SSL, RPC over an encrypted transport, or IIS's HTTPS support all consume TLS through one consistent, system-maintained implementation.

Not every app uses it, and that's a meaningful distinction to notice

A significant, practically useful fact: not all software on Windows uses Schannel and CNG. Plenty of cross-platform applications bundle their own TLS stack (commonly OpenSSL) specifically so their behavior is identical across operating systems. This is a legitimate engineering choice, but it has real consequences: system-wide certificate trust policy, TLS version restrictions set via Group Policy, and FIPS-mode enforcement generally only affect components actually using Schannel — a bundled OpenSSL stack inside a third-party application follows its own, separately-configured trust store and protocol settings, invisible to and unaffected by the system's own crypto policy.

A worked example: TLS to a domain controller

LDAP-over-SSL and related domain-authentication traffic (channel-bound alongside Kerberos in various configurations) typically flows through Schannel, consulting the machine's system certificate stores for trust decisions. This is why deploying a new internal CA certificate machine-wide, via Group Policy, correctly affects that traffic — but wouldn't automatically be trusted by, say, a bundled-OpenSSL cross-platform tool running on the same machine, which is consulting an entirely separate certificate store of its own.

A common mistake

Assuming "it's Windows, so it must be using the system crypto stack" when troubleshooting TLS or certificate-trust issues in a specific application is a common and time-wasting mistake. Whether a given piece of software uses CNG/Schannel or its own bundled crypto library fundamentally changes which trust store, which policy settings, and which diagnostic tools are actually relevant — worth confirming directly (which library the process has loaded is usually visible with the same tooling used elsewhere in this course to inspect loaded modules) before assuming system-level crypto policy explains observed behavior.

Where this connects

• Kerberos, NTLM, and authentication packages is one of several SSPI-based consumers of the same underlying framework Schannel plugs into.
• The DLL loader is the mechanism that determines which crypto library — system CNG/Schannel or a bundled alternative — a given process actually ends up using at runtime.