Question

I have a WCF service that needs to be secured via https. The WCF service server site and the clients consuming the WCF service are both self developed.

I generated a self-sign certificate and used it in my service with help from the following how-to article: http://msdn.microsoft.com/en-us/library/ff647171.aspx.

My service’s binding and behavior configuration is as follows:

<behaviors>
  <serviceBehaviors>
    <behavior name="SecureServiceBehavior">
      <serviceMetadata httpGetEnabled="true" />
      <serviceDebug includeExceptionDetailInFaults="false" />
      <serviceCredentials>
        <serviceCertificate findValue="CN={my server's ip address}" />
        <userNameAuthentication userNamePasswordValidationMode="MembershipProvider"
          membershipProviderName="SqlMembershipProvider" />
      </serviceCredentials>
      <serviceAuthorization principalPermissionMode="UseAspNetRoles"
        roleProviderName="SqlRoleProvider" />
        <serviceThrottling maxConcurrentCalls="128"
                           maxConcurrentSessions="128"
                           maxConcurrentInstances="128" />
    </behavior>
  </serviceBehaviors>
</behaviors>
<bindings>
  <wsHttpBinding>
    <binding name="MyBinding">
       <security mode="TransportWithMessageCredential">
          <message clientCredentialType="UserName"/>
       </security>
    </binding>
  </wsHttpBinding>
</bindings>

All WCF clients are employees of our company that will access the system over the Internet by IP address. I will add the server’s certificate to the trusted certificate authorities of each client computer.

Is such a configuration secure enough?

Answer 1

I’m not sure if you understand what it means for a certificate to be secure.
The thing is, you might say that all modern certificates are created equal. Modern hashing and encryption algorithms are freely available, and they’re all virtually unbreakable. What separates secure and insecure certificates are issues of trust.

Certificates are created to identify trusted servers in a potentially hostile network. You might compare them to a police badge or an ID, though I guess there is a little bit more to it than that. As such, the primary questions regarding a certificate’s validity are:

• Do I recognize the certificate at all? (Do I recognize the type of ID at all?)
• Does the certificate match the server using it? (Does the photo resemble the bearer?)
• Could the certificate have been compromised? (Could the ID have been stolen?)
• Could the root CA have been compromised? (Could someone make a forged ID?)

The problems in creating a secure certificate are analogous to the questions regarding its validity:

• Installing the certificate on all clients meant to recognize the server.
• Making sure the server matches the certificate
• Securing the certificate, and the root CA.

When all clients and servers are intimately aware of each other (such as being in the same company; your case), it is possible to use a self-signed certificate and manually install it on all clients so that they will recognize it. Since the server isn’t open for external requests (from just anyone), security isn’t an issue either. So, in short, as long as you abide by the standard security guidelines, a self-signed certificate is fine, in your case.

The problem occurs when you must identify your server to external visitors. For example, if I wanted to consume your web service, my computer wouldn’t have any notion of the certificate you’re using (since a self-signed certificate must be explicitly installed on each computer that needs to be aware of it), so the https functionality would be useless. In this case, you’ll have to obtain a certificate from a widely recognized CA (which probably costs money). This wouldn’t be any more intrinsically secure than a self-signed certificate, but it would be much more trustworthy.