2009-11-09 1 views
10

[Update] - Я придаю также полные файлы конфигурации, для service, и client (за пределами здесь, чтобы не флудить в теме)Сертификат службы WCF и идентификация конечной точки клиентской стороны - почему это не работает?

У меня ситуация в значительной степени идентична той, изложенной в this вопрос, однако мой вопрос несколько иной.

  • Я использую NetTcpBinding с безопасностью набором для TransportWithMessageCredential
  • Я использую Пароль/Имя пользователя учетных данные резервную копию с помощью ASP.NET провайдера
  • Моей службы самодостаточна в ОСАХ Windows Service
  • I do имеют в моей конечной точке поведение указанная аутентификация revocationMode = "NoCheck"

Необходимо, чтобы служба предоставляла сертификат для аутентификации клиентам. Это нормально, я просто делаю:

<serviceCertificate findValue="***" 
        storeLocation="CurrentUser" 
        storeName="My" 
        x509FindType="FindByThumbprint"/> 

Теперь я немного представлял себе, что теперь клиент будет в конечном итоге,

<identity> 
    <certificate encodedValue="encoded certificate"/> 
</identity> 

И это будет иметь возможность проверить полномочия предоставления услуг для без установленного этого сертификата в магазин на клиентской машине.

Я был удивлен to learn, что, хотя я установил служебные учетные данные сертификата, WSDL выставляет

<Identity> 
    <Dns>Foo</Dns> 
</Identity> 

Опять же, на службе я могу установить идентичность в CertificateReference и подключить его к тому же сертификат, а затем WSDL будет разоблачить идентичность как X509Certificate, но когда я запускаю клиент, настройка игнорируется, и я в конечном итоге с сообщением об ошибке:

System.ServiceModel.Security.SecurityNegotiationException: X.509 Cer tificate CN = xxx не находится в магазине доверенных людей. Сертификат X.509 CN = xxx здание цепочки не выполнено. В сертификате, который был использован , существует цепочка доверия, которая не может быть подтверждена . Заменить сертификат или изменить сертификатValidationMode. Цепочка сертификата обработана, но завершен в корневом сертификате, которому не доверяет поставщик доверия.

Есть ли способ заставить клиента использовать это значение из конфигурации и работы без необходимости установки сервисного сертификата (или его корня) на компьютере клиента?

[UPDATE] При установке certificateValidationMode никто не сделает исключение уйти, это неприемлемо решение с точки зрения безопасности.

Это заставляет клиента просто признать, что он получает сертификат «некоторые», не вдаваясь в подробности. Это делает возможным весь диапазон людей в средних атаках. Он по-прежнему не будет проверять информацию, отправленную (предполагаемой) службой, на сертификат, сбрасываемый в конфиге.

ответ

4

Решение Эскиз:

1) Определение и зарегистрировать пользовательские X509CertificateValidator на клиенте

2) в методе Validate, сравните данный сертификат с одной присутствующей в EndpointAddress клиента .Identity Недвижимость. Объект, на который ссылается это свойство, должен иметь точный тип X509CertificateEndpointIdentity.

Я не тестировал это решение, но для меня это имеет смысл.

НТН Педро

+0

Это то, что я закончил делать. У меня есть вопрос хотя - почему это не работает из коробки? Если у клиента есть вся необходимая информация и получает какой-либо сертификат от службы, это наиболее естественная вещь, чтобы сделать это для проверки Другие. Почему WCF не делает этого? –

+0

Гипотеза: из соображений безопасности. Используя предлагаемое решение, безопасность процесса импорта WSDL становится еще более важной, поскольку при общении с сервисом не будет выполняться дополнительная проверка сертификата. –

+0

Я только что начал щедрость по моему собственному вопросу, который кажется похожим на то, что вы здесь говорите. Если вы можете более подробно изложить решение, я бы очень признателен за это! http://stackoverflow.com/questions/4579666/wcf-newbie-how-to-install-and-use-a-ssl-certificate –

0

Вы являетесь причиной и практически завершите настройку конфигурации клиента. У вас не хватает одну вещь (как указано в описании ошибки): вам нужно установить revocationMode к NOCHECK в конфигурации:

<behaviors> 
    <endpointBehaviors> 
    <behavior name="SecureMessageUserName"> 
     <clientCredentials> 
     <serviceCertificate> 
      <authentication revocationMode="NoCheck"/> 
     </serviceCertificate> 
     </clientCredentials> 
    </behavior> 
    </endpointBehaviors> 
</behaviors> 

Если вам нужно больше деталей, просто дайте мне знать, и я выложу полная рабочая конфигурация клиента.

Edit извините за задержку

Вы должны также добавить NOCHECK в конфигурации сервера:

<behavior name="X509SecureBehavior"> 
      <serviceMetadata httpGetEnabled="true" /> 
      <serviceDebug includeExceptionDetailInFaults="true" /> 
      <serviceCredentials> 
      <serviceCertificate storeName="My" storeLocation="CurrentUser" x509FindType="FindByThumbprint" findValue="aaaa" /> 
      <clientCertificate> 
       <authentication certificateValidationMode="None" revocationMode="NoCheck" /> 
      </clientCertificate> 
      </serviceCredentials> 
     </behavior> 

Также я не включил ссылку сертификата в определении конечной точки.

+0

К сожалению, я забыл упомянуть, что у меня есть этот вариант набора. Я соответствующим образом обновил этот вопрос. В любом случае, сертификат, кажется, игнорируется, независимо от того, что я укажу здесь. –

+0

Вы можете отправить полный файл конфигурации? или значительную его часть? – AlexDrenea

+0

Конечно, я могу связать их, потому что они довольно большие, и я не хочу отпугивать потенциально полезных людей, утопая их в тоннах xml. –

2

[UPDATE] При установке certificateValidationMode в этом никто не будет сделать исключение уйти, это неприемлемо решение от безопасности точки зрения.

Это означает, что клиент только подтверждает , что он получает сертификат '' some '', , не вдаваясь в подробности. Это делает весь круг людей в середине возможных атак. Он по-прежнему не будет проверять информацию, отправленную службой (предположительно) против сертификата , сбрасываемого в конфигурацию.

Вы ошибаетесь. Это будет отлично. Это на самом деле то, что вы хотите - ваш сертификат на не будет подтвержден. Все, что вам нужно, это установить личность конечной точки на клиенте

<identity> 
    <certificate encodedValue="encoded certificate"/> 
</identity> 

Когда клиент подключается к WCF сервера будет сравнивать два сертификата и бросить исключение, если они не совпадают. И вы совершенно в безопасности.

Использование специального валидатора, такого как Предлагаемый Pedro Felix совершенно не нужен в вашем случае. Именно для этой цели является конечная точка.

+0

Это вводит в заблуждение - установка сертификатаValidationMode в None означает, что у вас может быть любой закодированныйValue, и он не будет проверить. –

1

Это дополнительный комментарий к моему предыдущему ответу. Извините, я не могу комментировать ответы.

Кроме того, вы делаете не необходимо установить любой идентификатор на сервере. Забудьте о том, что WSDL сообщает вам о личности сервера. Идентификация конечной точки удаленного сервиса определяется клиентом во время выполнения. Если сервер использует SSL, он имеет несколько идентификаторов: общее имя сертификата (то есть идентификатор DNS), идентификатор сертификата и идентификатор RSA (не уверен в последнем). Таким образом, вы можете проверить личность сервера любым из этих критериев (или несколькими из них).

2

Извините, я не могу комментировать другие ответы.

Я только что протестировал это в .NET 4.0, и я могу подтвердить, что ответ «Zeratul» верен. Явно настраивает идентификатор службы либо в конфигурации, либо программно достаточно для аутентификации сервера. Нет необходимости проверять сертификат другими способами (т. Е. Вы можете установить «certificateValidationMode» на «None»), поскольку вы используете метод окончательной проверки - сравнение отпечатка сертификата.

@AlexDrenea

"serviceCertificate" не используется для проверки. Он используется с защитой сообщений для шифрования сообщений до их отправки на сервер. Обратитесь к документации Microsoft, об этом:

http://msdn.microsoft.com/en-us/library/ms731782.aspx

 Смежные вопросы

  • Нет связанных вопросов^_^