Certificate based Authentication and WCF

Certificate based authentication with WCF has two components – configuring credentials and determining trust.

The first part is easy – you simply set the clientCredentialType in the binding’s security configuration to Certificate. This means that WCF will demand that the client sends a certificate along with the (first) request – either as a WS-Security X509 token or using SSL client certificates (depending on the security mode this also means that this requirement becomes part of the WSDL/Policy).

Furthermore the “plumbing” (either SSL or WCF message security) will make sure that the incoming certs are technically valid. This includes making sure that the certificate is not malformed and that the signature matches the public key. If this is not the case, the request gets rejected at a very low level and usually your service code would never get invoked.

At this point you have a technically valid certificate – but this does not necessarily mean that you also trust that certificate. The default validation strategy for certificates (regardless of message vs. transport) is called Chain Trust, this means:

  • the certificate must be issued from a CA in your trusted CA list (in the machine certificate store)
  • this intended purpose of that CA must include “Client Authentication”
  • the current date/time must be within the certificate’s validitiy period

With message security you also get a mode called Peer Trust. In this mode WCF simply checks if the incoming certificate is installed in the Trusted People folder in the certificate store (the expiration time is checked too).

When to use which mode?

Peer Trust
Since the Trusted People folder must hold all allowed certificates, this means that the service (or the client) has to know every peer a priori. This is OK if you have a limited amount of certificates that you want to allow – but does not scale very well. If you have more than one service on a machine and want to use peer trust, you have to run them under different accounts and use the current user certificate store to separate the “allowed” list.

Chain Trust
Chain trust is for scenarios where you don’t know every certificate explicitly, but want to establish trust based on the issuer. The problem you have here is, that by default the trusted CA list is quite, errm, extensive. It includes popular CAs like VeriSign and not so popular ones (which I never heard before). So using chain trust it is quite easy to get a certificate that would be trusted by your service.

So in a lot of cases peer trust is not enough and chain trust is too much. What you typically want to have is first validating the trust chain and afterwards restrict to a specific CA or specific properties in the client cert. How do you accomplish that? Well – it depends ;)

In classic SSL transport security this is accomplished by using a Certificate Trust List (CTL). The moral equivalent in message based security is a X509 Certificate Validator. A third approach (which works in both modes) would be a WCF Service Authorization Manager.

In the next posts I will have a look at these technique and show you the up/downsides of each. Stay tuned.

This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to Certificate based Authentication and WCF

  1. Noven says:

    I am developing a WCF client in C# (windows form application) to call a Java base web service with certificate. But I always get response
    T9WSC Certificate missing or invalid owner) ‘.

    I attach the App.config as following

    The chained certificates are installed in my local PC like following
    -Root CA in Current User->Trusted Root Certification Authorities
    -Server CA in Current User ->Intermediate Certification Authorities
    -Application CA in Current User-> Personal
    And I could view the full certificate chain when I open the Application Certification Path

    As far as I can see, the problem is that my application could not TRUST the certificate, and when I use Fiddler to track the SOAP request and response, I do not see the certificate was a part of the request, but the Response contains certificate info.

    The Fiddler Inspectors TextView of the request is
    A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
    Version: 3.1 (TLS/1.0)
    Random: 57 8F 36 F3 42 E7 E9 83 3D A6 AA BC D9 11 D7 77 78 7E 97 57 4D DD AD E9 07 71 C9 2F E8 43 7A 53
    “Time”: 21/04/2099 09:18:47
    SessionID: empty
    server_name some name
    elliptic_curves secp521r1 [0x19], secp256r1 [0x17], secp384r1 [0x18]
    ec_point_formats uncompressed [0x0]
    extended_master_secret empty
    renegotiation_info 00
    [0035] TLS_RSA_AES_256_SHA
    [002F] TLS_RSA_AES_128_SHA
    [0038] TLS_DHE_DSS_WITH_AES_256_SHA
    [0032] TLS_DHE_DSS_WITH_AES_128_SHA
    [0005] SSL_RSA_WITH_RC4_128_SHA
    [0004] SSL_RSA_WITH_RC4_128_MD5


    The response is
    Encrypted HTTPS traffic flows through this CONNECT tunnel. HTTPS Decryption is enabled in Fiddler, so decrypted sessions running in this tunnel will be shown in the Web Sessions list.

    Secure Protocol: Tls
    Cipher: Aes256 256bits
    Hash Algorithm: Sha1 160bits
    Key Exchange: RsaKeyX 2048bits

    == Server Certificate ==========
    CN=xxx, O=xxx, DC=xxx, DC=com

    CN=xxx, OU=PKI, O=xxx, C=xx

    [Serial Number]

    [Not Before]
    14/04/2016 08:34:30

    [Not After]
    15/10/2016 19:00:00



    I have spent >1 week on It but still could not solve the problem. Would be very much appreciated if you could give me some idea how to get it work.

    Thank you in advance,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s