Как правильно реализовать аутентификацию сертификата клиента?

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

Надеюсь получить ответы от сообщества. Мы очень приветствуем обратную связь по любому предположению или вопросу.

Для протокола: чтобы действительно принять один ответ, я должен разделить этот пост на несколько вопросов, но это приведет к еще большей путанице. Я почти уверен, что в сети есть настоящие эксперты по WCF, которые могут ответить сразу на несколько вопросов в этом документе, поэтому я могу принять один ответ как реальную сделку для правильной настройки аутентификации по сертификату клиента с использованием IIS.

Позвольте мне обрисовать ситуацию и запрос партнера:

1: Требование к партнеру и вопрос об использовании клиентского сертификата.

Партнеру X необходимо вызвать API на моем бэкэнде, и у него есть четкое требование использовать аутентификацию Clientcertificate. Они создали клиентский сертификат и предоставили нам сертификат только с открытым ключом, поскольку кажется, что это единственная логика, в которой они сохраняют закрытый ключ фактически закрытым и в своей собственной системе (системах). Сертификат был импортирован в локальную учетную запись компьютера, и судя по пути сертификации, он действителен. Все промежуточные центры сертификации и, в конце концов, корневой центр сертификации являются доверенными.

2: Наша серверная конфигурация WCF

У меня есть serviceBehavior, настроенный как таковой:

<behavior name="ClientCertificateBehavior">
    <serviceMetadata httpsGetEnabled="true" />
        <serviceCredentials>
        <serviceCertificate findValue="<serialnumber here>" x509FindType="FindBySerialNumber" />
        <clientCertificate>
          <authentication certificateValidationMode="PeerTrust" />
        </clientCertificate>
    </serviceCredentials>
</behavior>

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

Служба настроена так:

<service behaviorConfiguration="ClientCertificateBehavior" name="<Full service namespace and servicename>">
    <endpoint binding="basicHttpBinding" bindingConfiguration="Soap11CertificateBasicHttpBinding"
        contract="<The interface>"></endpoint>
</service>

Привязка выглядит так:

Это basicHttpBinding для принудительного использования SOAP1.1 (в соответствии со спецификациями партнера).

<binding name="Soap11CertificateBasicHttpBinding">
  <security mode="Transport">
    <transport clientCredentialType="Certificate" />
  </security>
</binding>

3: Размещение службы WCF в IIS и конфигурация IIS

Мы размещаем наши службы WCF в IIS7. Мы настроили папку, в которой находятся службы, так, чтобы она требовала SSL и принимала клиентские сертификаты. Включена анонимная аутентификация на основе аутентификации.


Дело в том, что связь с партнером работает, и мы были уверены, что все в порядке, однако переключение настройки IIS на «требовать» сертификат клиента показывает нам, что внезапно больше невозможно успешно вызвать нашу службу.

Правильно ли я предполагаю, что следующие вещи не выполняются правильно:

  • ServiceCerticate в serviceBehavior на самом деле не нужен. Это настройка, используемая клиентом. Или необходимо предоставить эту информацию о сертификате для конечной точки службы, чтобы она соответствовала сертификату, отправляемому клиентом?

  • Чтобы проверка подлинности clientcertificate действительно работала в IIS, сертификат необходимо сопоставить с пользователем. Этому пользователю должны быть предоставлены права доступа к папке, содержащей службы, и все механизмы аутентификации (анонимные, оконные и т. д.) должны быть отключены. Таким образом, IIS обработает фактическое рукопожатие и проверит связь службы. Или это больше вопрос дополнительной безопасности, связанной с сопоставлением сертификата с пользователем?

    • Установив «Принять» в IIS, мы обходим фактическую проверку сертификата между клиентом и сервером.

    • Все механизмы аутентификации, такие как «анонимный» и «окна», должны быть отключены в IIS для папки, в которой находятся службы.


person Guillaume Schuermans    schedule 18.01.2013    source источник


Ответы (1)


В вашем сценарии вам не нужно настраивать сертификаты в WCF, IIS обрабатывает их за вас. Вы можете очистить весь блок <serviceCredentials>, потому что:

<serviceCertificate> of <serviceCredentials> указывает сертификат X.509, который будет использоваться для аутентифицировать службу для клиентов, используя режим безопасности сообщений, который вы не используете, и <clientCertificate> из <serviceCredentials> определяет сертификат X.509, используемый для подписи и шифрования сообщений, отправляемых клиенту из службы по шаблону дуплексной связи.

См. здесь, как сопоставить клиентские сертификаты с учетными записями пользователей.

person CodeCaster    schedule 21.01.2013
comment
Это четкое заявление, спасибо за это. Не могли бы вы ответить на вопрос, должен ли я установить сертификат «требовать» вместо сертификата «принять», чтобы иметь место фактическая проверка сертификата? - person Guillaume Schuermans; 21.01.2013
comment
И еще один вопрос, на который вы, вероятно, сможете ответить так же ясно. Требуется ли это сопоставление пользователей и отключение анонимной проверки подлинности для правильной работы проверки подлинности сертификата? - person Guillaume Schuermans; 21.01.2013
comment
@GuillaumeSchuermans Я не могу найти определенный источник для принятия/требования. Что касается сопоставления: если вы не сопоставляете сертификаты, IIS не будет знать, кто аутентифицируется с использованием данного сертификата, поэтому любой, у кого есть действительный сертификат, который связан с доверенным корнем на сервере, может получить доступ к службе, если никакая другая безопасность на месте. - person CodeCaster; 21.01.2013
comment
Клиент (партнер) общается с использованием сертификата, который имеет закрытый ключ. Они предоставили нам сертификат для установки в IIS, который имеет только открытый ключ. Думаю, я могу гарантировать тот факт, что только тот, у кого есть сертификат с закрытым ключом, сможет связаться с моей службой? - person Guillaume Schuermans; 21.01.2013
comment
При желании вы также можете ответить на этот вопрос: stackoverflow.com/questions/14440777/, так как на самом деле было странно просить много только один вопрос, и вы заслуживаете немного больше репутации за то, что копаетесь в этой проблеме. Это также поможет другим легче найти ответ на вопрос сопоставления сертификатов. - person Guillaume Schuermans; 21.01.2013
comment
@GuillaumeSchuermans, они, вероятно, предоставили вам открытый ключ, потому что это был самозаверяющий сертификат. Они не являются доверенными и не могут использоваться для аутентификации по умолчанию, поэтому вы установили их в хранилище доверенных корневых центров для локального компьютера на сервере IIS. Правильный? - person CodeCaster; 21.01.2013
comment
Это не самозаверяющий сертификат, а сертификат промежуточного центра, который, в свою очередь, конечно же, имеет сертификат корневого центра. Цепочка сертификатов в их среде такая же, как и в нашей. - person Guillaume Schuermans; 21.01.2013