Привет там. Поскольку больше никто не ответил, я попытаюсь разобраться с этим - но справедливо предупреждаю - я являюсь разработчиком Java / UNIX, и кое-что из того, что вы спрашиваете, относится именно к Microsoft. Но вот несколько ответов:
1 - выдать сертификат с
CN = app-server-NLB-hostname и
Цель проверки подлинности сервера в
домен CA.
Цель - это что-то особенное для Microsoft. Это звучит правильно, но также - вам может понадобиться регулярное «использование ключа», чтобы быть чем-то конкретным - для сертификатов SSL я обычно использую keyEncipherment или keyAgreement. Иногда сайты используют digitalSignature. Все три действительны в RFC, но иногда Microsoft недовольна тем, что работает. Если вы используете Microsoft CA, я посмотрю, есть ли у него профиль сертификата для SSL-сертификатов, и просто используйте его.
2 - выдать сертификат для front-end
поля с надписью «Аутентификация клиента»
цель.
То же, что и # 1 - каждый сертификат требует своего рода базового использования ключа. Поля, которые вы упоминаете, являются расширенными использованиями, которые, вероятно, также необходимы, но не обязательны.
3 - импортировать публичный внутренний сертификат
ключ в хранилище интерфейсных узлов
(и наоборот).
Только если это особенность Microsoft. В правильной PKI вы должны импортировать сертификат доверенного CA, который подписал SSL, но вы НЕ должны импортировать каждую конечную точку (например, сертификат сервера) в интерфейс. Я бы попробовал сделать это только с настройкой цепочек доверенных ЦС и посмотреть, сможете ли вы заставить его работать - это сделает вашу архитектуру гораздо более расширяемой в долгосрочной перспективе.
4 - настроить WCF для использования net.tpc с
транспортная безопасность
5 - настроить поведение службы
(раздел serviceCredentials)
6 - настройка конечной точки клиента
поведение (раздел clientCredentials)
Звучит хорошо для меня ...
Оттуда я не думаю, что вы пропустили что-нибудь еще. Ключ обычно работает через непонятные сообщения об ошибках. У каждой системы есть свой непостижимый способ сказать, что не так, когда не удается установить рукопожатие SSL, поэтому в большинстве случаев возникает ощущение того, что пошло не так.
Из описанной вами проблемы я не думаю ваша архитектура безопасности говорит, что вам нужно проверить статус сертификата. Это дополнительная мера, которая позволит вашей системе проверять, был ли сертификат отозван центром сертификации. Для того, чтобы все заработало (CRL или OCSP), нужно потратить немного времени, поэтому я бы не сказал, что вам следует обратиться к нему без серьезного обсуждения вашей команды о том, какие риски вы пытаетесь снизить, и насколько высока вероятность их происходят.
Для каких сертификатов внешнего интерфейса хоста должны быть выданы?
Имя хоста сервера, который они представляют.
Что касается имен хостов - некоторые системы не будут работать должным образом, если вы не используете полное доменное имя. Другие не так придирчивы. В любом случае - DN субъекта сертификата должен однозначно описывать сервис, приложение или сервер, который он представляет.
Внешние узлы находятся в DMZ, поэтому не будут иметь доступа к домену (CA). Это вызовет какие-либо проблемы?
У вас не будет проблем.
UNLESS - необходимо выполнить вышеупомянутую проверку статуса сертификата. Если вам нужно проверить статус сертификата, то вам нужно перейти от конечной точки (т. Е. DMZ) к информации о статусе сертификата (CRL или сервер OCSP). В сложных инфраструктурах это обычно делается путем открытия пути к серверу OCSP - это HTTP-запрос GET к фиксированному доменному имени или IP-адресу, поэтому обычно неплохо открыть путь на брандмауэре.
Как я уже сказал, это было бы высококлассное, серьезное решение для снижения риска. Это может быть излишним для вашей системы - я не знаю достаточно о вашей системе, чтобы сказать вам, гарантировано ли это или нет.