I have followed and investigated a lot of tutorials online for creating a WCF service that uses certificate authentication to authenticate a client connecting to our WCF service with a certificate.
So, when I test this out:
The problem I have here is, if I test this again and I select whatever other certificate that I have it also works. It doesn't matter what certificate I select I'm always able to access the WSDL.
My service is running on Azure as a Web App. The following is my configuration on my service.
Binding
<wsHttpBinding>
<binding name="wsCertBinding">
<security mode="Transport">
<transport clientCredentialType="Certificate"/>
</security>
</binding>
</wsHttpBinding>
Behavior
<behavior name="certificateServiceBehavior">
<serviceMetadata httpGetEnabled="false" httpsGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
<serviceCredentials>
<clientCertificate>
<authentication certificateValidationMode="PeerTrust" />
</clientCertificate>
<serviceCertificate findValue="THUMBPRINT-SELF_SIGNED_CERT"
storeLocation="CurrentUser"
storeName="My"
x509FindType="FindByThumbprint"/>
</serviceCredentials>
</behavior>
So, why am I able to select a random certificate when I access my endpoint through the browser?
My expectation was that only my self-signed certificate is able to access my service.
You can use the certificate's encoding to verify it. Because the encoding of each certificate is unique.
The client configuration file joins this code:
<client>
<endpoint address="..."
binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IService1"
contract="ServiceReference1.IService1" name="WSHttpBinding_IService1" behaviorConfiguration="Service1Nehavior">
<identity>
<certificate encodedValue="..."
/>
</identity>
</endpoint>
</client>
<certificate encodedValue="...": The value here is the encoded value of your certificate. If there is a discrepancy, the verification cannot be completed.