WCF Certificates

A WCF service that uses HTTPS transport or message-level encryption needs a service certificate — an X.509 certificate with an accessible private key, installed in a Windows certificate store, that the service presents so clients can verify the service's identity and establish an encrypted channel. This is configured via ServiceCredentials.ServiceCertificate.SetCertificate(), specifying the store location (LocalMachine or CurrentUser), store name (typically My), and how to find the certificate (by thumbprint, subject name, or serial number). A client certificate serves the reverse purpose: when clientCredentialType is set to Certificate, the client presents its own X.509 certificate to authenticate itself to the service, configured via ClientCredentials.ClientCertificate.SetCertificate() on the client and validated against a trust policy on the service, which can range from full chain trust validation against a CA to a simpler PeerOrChainTrust or an explicit list of trusted thumbprints.

Windows certificate stores are organized by location and name: LocalMachine\My is the standard place for a service's own certificate (accessible to the service process regardless of which user account it runs under, which matters for IIS-hosted services running as an application pool identity), while CurrentUser\My is more common for client applications or developer testing. Trust decisions rely on LocalMachine\Root (trusted root CAs) and LocalMachine\TrustedPeople (explicitly trusted individual certificates, useful for self-signed certs in test environments where you don't want a full CA chain). WCF locates a specific certificate using a combination of x509FindType (such as FindByThumbprint, FindBySubjectName, or FindBySerialNumber) and a findValue string; FindByThumbprint is generally preferred in production because it's unambiguous, whereas FindBySubjectName can accidentally match multiple certificates if an old one hasn't been cleaned up, causing WCF to throw an ambiguous-match exception at startup.

The most common production incident with WCF certificates isn't a security bug but expiry: certificates have a validity window, and when a service certificate expires, every client suddenly fails the TLS handshake or WS-Security validation with cryptic errors like 'The X.509 certificate CN=... is not in the trusted people store' or 'could not establish trust relationship,' which look like configuration problems even though the real cause is a missed renewal date. Beyond expiry, private key access is a frequent deployment trap: the account running the WCF host (an IIS application pool identity, or a Windows service account) needs explicit permission to read the certificate's private key, granted via certlm.msc's 'Manage Private Keys' option or the certutil -repairstore command, and forgetting this step produces access-denied errors that only manifest at runtime, not at certificate installation time.