我在.NET 4.0下有一个使用WIF 3.5和ws2007FederationHttpBinding绑定的WCF服务。目前它正在（成功）作为自托管服务运行，但我更希望它在IIS7.5下运行。但是我无法让它发挥作用。
我对此没有深入的了解或经验，所以我通过简单地将用于自托管的配置复制到web.config来解决这个问题。
除了添加behaviors\servicebehaviors\behavior\serviceCredentials\serviceCertificate之外，它们几乎相同，在IIS托管的情况下似乎是必需的，但不是自托管（我不知道为什么）。
对于两种服务设置（除了端点地址），客户端配置也是相同的。
测试自托管和IIS托管服务发生在同一台机器上，我尝试使用VS开发服务器，IIS Express和常规IIS进行IIS托管服务。
客户端在同一台机器上。
STS在另一台机器上。
涉及3个（x509）证书。服务证书和STS使用的签名证书，均在自签名根证书下。 DefaultAppPool（托管Web服务的位置）可以访问这两个证书。 据我所知，没有涉及SSL。
我可以运行IIS托管服务，我可以请求元数据。我发出实际请求时会发生错误。 客户端错误似乎非常通用：
An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.
An error occurred when verifying security for the message.
客户端的svc跟踪日志几乎相同。
服务器错误不会引发错误，但svc日志会显示：
The X.509 certificate CN=sts.public.example.com chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. The revocation function was unable to check revocation for the certificate.
System.IdentityModel.Selectors.X509CertificateChain.Build(X509Certificate2 certificate)
System.IdentityModel.Selectors.X509CertificateValidator.ChainTrustValidator.Validate(X509Certificate2 certificate)
System.IdentityModel.Selectors.X509SecurityTokenAuthenticator.ValidateTokenCore(SecurityToken token)
System.IdentityModel.Selectors.SecurityTokenAuthenticator.ValidateToken(SecurityToken token)
System.IdentityModel.Selectors.SamlSecurityTokenAuthenticator.ResolveClaimSet(SecurityToken token)
System.IdentityModel.Selectors.SamlSecurityTokenAuthenticator.ValidateTokenCore(SecurityToken token)
System.IdentityModel.Selectors.SecurityTokenAuthenticator.ValidateToken(SecurityToken token)
System.ServiceModel.Security.ReceiveSecurityHeader.ReadToken(XmlReader reader, SecurityTokenResolver tokenResolver, IList`1 allowedTokenAuthenticators, SecurityTokenAuthenticator& usedTokenAuthenticator)
System.ServiceModel.Security.ReceiveSecurityHeader.ReadToken(XmlDictionaryReader reader, Int32 position, Byte[] decryptedBuffer, SecurityToken encryptionToken, String idInEncryptedForm, TimeSpan timeout)
System.ServiceModel.Security.ReceiveSecurityHeader.ProcessEncryptedData(EncryptedData encryptedData, TimeSpan timeout, Int32 position, Boolean eagerMode, Boolean& primarySignatureFound)
System.ServiceModel.Security.ReceiveSecurityHeader.ExecuteFullPass(XmlDictionaryReader reader)
System.ServiceModel.Security.ReceiveSecurityHeader.Process(TimeSpan timeout, ChannelBinding channelBinding, ExtendedProtectionPolicy extendedProtectionPolicy)
System.ServiceModel.Security.MessageSecurityProtocol.ProcessSecurityHeader(ReceiveSecurityHeader securityHeader, Message& message, SecurityToken requiredSigningToken, TimeSpan timeout, SecurityProtocolCorrelationState[] correlationStates)
System.ServiceModel.Security.SymmetricSecurityProtocol.VerifyIncomingMessageCore(Message& message, String actor, TimeSpan timeout, SecurityProtocolCorrelationState[] correlationStates)
System.ServiceModel.Security.MessageSecurityProtocol.VerifyIncomingMessage(Message& message, TimeSpan timeout, SecurityProtocolCorrelationState[] correlationStates)
sts.public.example.com是STS的签名证书。 我不知道在哪里放置这个certificateValidationMode以及为什么它应该与IIS有任何不同。
对于身份模型和serviceAuthorizationManager，有一个自定义issuerNameRegistry和claimAuthorizationManager用于服务行为，但是在错误之前都没有命中。因此，当服务器从客户端收到签名的令牌并且IIS本身无法验证证书（狂野的随机猜测）时，可能会发生错误。
我会给你配置文件和代码示例，但这一切都非常多，因为我不知道究竟什么是相关的，什么不是，但如果需要澄清，我会尽快添加它
我尝试在任何可能的地方关闭certificateValidation和吊销检查，并且摆弄了我几乎无法理解的许多设置。 This post似乎有希望，但我并没有真正看到建议的解决方案适合的位置，并且考虑到它可能已经不再适用的日期。
如果有人能指出解决方案的方向和/或解释自托管服务和IIS托管服务之间的设置/配置要求的差异，那将是非常有用的。