I wanted to put up this sample using the Feb CTP.
Basically it uses WSE 3.0 and WCF to demostrate both AnonymousCertificate configuration and MutualCertificate configuration using the service custom binding Configuration and the WSE policy file.

The point is that WSE uses MessageVersion.Soap11WSAddressingAugust2004 or MessageVersion.Soap12WSAddressingAugust2004 basically will need a custom binding for this.

I was looking into custom certificate validators sample and was quite curious on how I could chain the certificate validation and where Martin helped me out with this and this is prietty much how he put it.

 Here is a validator implementation that accepts self-issued certs, certs in the trusted people store and certs that chain to a trusted root CA;

class CustomValidator : X509CertificateValidator
{
 public CustomValidator()
 {
 }

 public override void Validate(X509Certificate2 cert)
 {
  if (cert.Subject == cert.Issuer)
   return;
  else
   X509CertificateValidator.PeerOrChainTrust.Validate ( cert );
 }
} 

If you wanted to do peer/chain and then extra checking, you'd reverse the order;

class CustomValidator : X509CertificateValidator
{
 public CustomValidator()
 {
 }

 public override void Validate(X509Certificate2 cert)
 {
  X509CertificateValidator.PeerOrChainTrust.Validate ( cert );

   if ( !CertIsOK ( cert )) 
     throw new SecurityTokenException ( "Certificate is not OK" (;
 }

  private bool CertIsOK ( X509Certificate2 cert )
  {
     bool bRet = false;

     // Perform checks here and set bRet to true if all checks are passed.

     return bRet;
  }
}

So basically what you can do is set the X509ValidationMode to None and then test your code. That way no matter whats wrong with the certificate, no checks will be done and the certificate will be accepted, then fix the certificate problem.

When using webservices we usually want the messages encrypted and also use SSL. This configuration as of now is not supported out of the box. We could use either tranport or message or a type called TransportWithMessageCredentials.
The 3rd type does not encrypt the soap message at the Message level but only supplies the claims(credentials) at this level. The security is pretty much provided at the Transport Level as the name should suggest.
The only binding that provides this out of the box is the following

<netMsmqBinding>
   <binding name="test">
       <security mode="Both"></security>
    </binding>
</netMsmqBinding>

WsHttpBinding provides a mixed mode but not both.
You can get a full listing here Predefined Bindings.

Incase you do want to use this you have to create a custom binding specifying each element. The behavior element can be used to specify the credentials that the message level security would use and the tranport can use say the server certificate from IIS. The snippet below shows a bare skeleton of this kind of binding.

<customBinding>
     <binding name="Binding1">
           <security authenticationMode="SecureConversation"
                           requireSecurityContextCancellation="true">
           </security>
           <textMessageEncoding messageVersion="Soap12WSAddressing10" writeEncoding="utf-8"/>
           <httpsTransport/>
      </binding>
</customBinding>

Ususally when tesitng with different certificates we usually need to check if the certificate chain is valid and this snippet came in quite handy in many places.

X509Certificate2 cert = FedUtil.LookupCertificate(StoreName.My, StoreLocation.LocalMachine, "CN=MyCertificate");
X509Chain chain = new X509Chain();
bool pass = chain.Build(cert);

Where this is what it is now "Windows Power Shell"

When setting up SSL, IIS requires a server certificate to be present. A simple developer setup would be to install certificate services  basically as a stand alone root CA and use it to get your server certificate.

You basically set the sever certificate using IIS snap-in. Navigate to the default website properties and on directory security you can set the server certificate. The point is that when doing this, online requests for server certificates can be made only to local and remote enterprise certificate services and remote standalone certificate services. So this means you would basically have to build an offline request and save the request file. You then submit it to your CA at http://<machinename>/certsrv by selecting 

1. Request a Certificate
2. Advanced certificate Request
3. Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.

You can then proceed where you left off on the IIS snap-in to setup the cert.
Read More

Yesterday we celebrated the 100th recruit. Its a nice feeling to be in the Campus here at Hyderabad and hear quite an inspiring speech by Sanjay Mirchandani.

To celebrate this, we got these personalized mugs which are quite cool. Hoping to see this organization grow.