Answered by:
WCF mapping certificate to windows account

Question
-
I need to have interoperable WCF service and want to use mapClientCertificateToWindowsAccount. But when this property is set to true I get "The X.509 certificate E=test@xxxx.com, CN=Test XXXX A2A cert, OU=IT, O=XXXX SR a.s., L=Bratislava, S=Slovakia, C=SK chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider."
My server web.config:
<system.serviceModel> <behaviors> <serviceBehaviors> <behavior name="serviceCredentialBehavior"> <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" /> <serviceDebug includeExceptionDetailInFaults="true" /> <serviceCredentials> <clientCertificate> <authentication mapClientCertificateToWindowsAccount="true"/> </clientCertificate> <serviceCertificate findValue="myserver.com" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectName" /> </serviceCredentials> </behavior> </serviceBehaviors> </behaviors> <services> <service behaviorConfiguration="serviceCredentialBehavior" name="WcfInteropService.Service1"> <endpoint address="" binding="wsHttpBinding" bindingConfiguration="InteropCertificateBinding" name="Service1EndP" contract="WcfInteropService.IService1" /> <endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange" /> </service> </services> <bindings> <wsHttpBinding> <binding name="InteropCertificateBinding" messageEncoding="Mtom"> <security mode="Message"> <message clientCredentialType="Certificate" establishSecurityContext="false" negotiateServiceCredential="false"/> </security> </binding> </wsHttpBinding> </bindings> <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true"/> </system.serviceModel>
My client config is:
<system.serviceModel> <behaviors> <endpointBehaviors> <behavior name="ClientCredentialsBehavior"> <clientCredentials> <clientCertificate findValue="InteropA2A" storeLocation="CurrentUser" storeName="My" x509FindType="FindBySubjectName"/> <serviceCertificate> <defaultCertificate findValue="myserver.com" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectName"/> </serviceCertificate> </clientCredentials> </behavior> </endpointBehaviors> </behaviors> <bindings> <wsHttpBinding> <binding name="Service1EndP" messageEncoding="Mtom"> <security mode="Message"> <message clientCredentialType="Certificate" negotiateServiceCredential="false" establishSecurityContext="false" /> </security> </binding> </wsHttpBinding> </bindings> <client> <endpoint behaviorConfiguration="ClientCredentialsBehavior" address="http://myserver.com:10022/T/Service1.svc" binding="wsHttpBinding" bindingConfiguration="Service1EndP" contract="UniService.IService1" name="Service1EndP"> <identity> <certificate encodedValue="MIIF2TCCBxGDAWBgoJ....cABzOMOrTPbL5scCCvKsBg==" /> </identity> </endpoint> </client> </system.serviceModel>
Thursday, July 28, 2016 2:46 PM
Answers
-
I've abandoned mapClientCertificateToWindowsAccount and the service is running as expected now with finding certificate user in AD in code.
Zdenok
- Proposed as answer by Tony---- Monday, August 1, 2016 9:52 AM
- Marked as answer by Edward8520Microsoft contingent staff Thursday, August 4, 2016 9:17 AM
Monday, August 1, 2016 8:59 AM
All replies
-
I've abandoned mapClientCertificateToWindowsAccount and the service is running as expected now with finding certificate user in AD in code.
Zdenok
- Proposed as answer by Tony---- Monday, August 1, 2016 9:52 AM
- Marked as answer by Edward8520Microsoft contingent staff Thursday, August 4, 2016 9:17 AM
Monday, August 1, 2016 8:59 AM -
Hi Zdenok,
Thanks for sharing.
For clientCertificate, how did you generate the certificate which map to windows Account? Is this certificate “CN=Test XXXX A2A cert” mapping to windows account? I am interesting in implementing mapClientCertificateToWindowsAccount.
Best Regards,
Tony
Help each other
Monday, August 1, 2016 9:35 AM