Недавно в интернете читал интересное обсуждение, в котором утверждалось, что самоподписанные сертификаты подвержены атаке Man-in-The-Middle (MiTM). Давайте разберёмся, что это такое. Есть 2 узла (А и Б). Узел А инициирует соединение с узлом Б отправляя запрос для предъявления сертификата (SSL). Узел Б посылает свой сертификат узлу А. И тут между узлами А и Б появляется узел В (злоумышленник), который перехватывает сертификат и вместо него отправляет свой поддельный сертификат. Узел А думает, что это сертификат узла Б и начинает шифровать этим сертификатом данные, передавая узлу Б. Но на самом деле узел А шифрует данные поддельным сертификатом узла В и злоумышленник читает все шифрованные (а это могут быть и конфиденциальные данные) данные.

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

• Симметричное шифрование

Самый простой, но и небезопасный метод:

1. John Smith хочет безопасно отправить конфиденциальные данные Mary Jane.
2. John генерирует симметричный ключ и шифрует им документ. Документ теперь зашифрован и может быть передан через интернет.
3. Mary Jane получает зашифрованный документ.
4. Mary Jane применяет *тот же самый* симметричный ключ и получает текст в незашифрованной форме.

Минус такого сценария заключается в том, что используется один и тот же ключ как для шифрования и дешифрования. Следовательно, чтобы Mary Jane смогла расшифровать данные ей нужно иметь тот же самый ключ. Этот ключ не должен передаваться вместе с документом, а какими-нибудь другими методами (например, по телефону). Чем больше получателей этого документа, тем выше вероятность, что ключ станет известен ещё кому-то и не существует механизмов, которые бы позволяли определять статус ключа (скомпрометирован или нет). Плюс такого сценария — высокая скорость. Симметричное шифрование выполняется достаточно быстро и не потребляет большого количества процессорных ресурсов. Идеально подходит для шифрования больших объёмов данных.

• Асимметричное шифрование

Метод более сложный, но и более безопасный:

1. John Smith хочет отправить конфиденциальные данные Mary Jane.
2. John использует открытую часть сертификата (с открытым ключом) Mary Jane и этим открытым ключом шифрует данные.
3. Mary Jane получает зашифрованный документ.
4. Mary Jane применяет *закрытый ключ* от своего сертификата и расшифровывает данные.

В нашем сценарии Mary Jane — это веб-сервер, которому нужно передать конфиденциальные данные. А John Smith — клиент, который хочет эти данные передать на сервер. Чисто технически злоумышленник может перехватить открытую часть сертификата Mary Jane и вместо него подложить свой поддельный сертификат с таким же именем. Без дополнительных мер безопасности, John не смог бы отличить настоящий сертификат от поддельного. И здесь появляется важный момент. Перед шифрованием данных John Smith должен проверить этот сертификат на доверие и отзыв. Сертификаты содержат различные средства определения статуса закрытого ключа через списки отзыва. Если сертификат помещён в список отзыва, ему доверять нельзя и использовать его крайне опасно. В случае с самоподписанными сертификатами определить отзыв не представляется возможным. Но можно (как минимум) убедиться, что сертификат выпущен доверенным лицом (или центром сертификации). Для этого John Smith пропускает сертификат через Certificate Chaining Engine (CCE). Если издатель сертификата (или сам сертификат) хранится у John'а в Trusted Root CAs, можно с уверенностью сказать, что сертификат не был подделан злоумышленником и выдан доверенным лицом. Если же сертификата там нет, невозможно убедиться, что это действительно сертификат самой Mary Jane. В таком случае приложение выдаёт ошибку или предупреждение, что не удалось проверить сертификат. Когда пользователь получил такое предупреждение, он должен незамедлительно отменить операцию шифрования (если это ещё не сделало само приложение).

Поскольку закрытый ключ от сертификата хранится только у Mary Jane и он никогда не раскрывается никому, злоумышленнику бесполезно использовать перехваченные пакеты, поскольку закрытый ключ (который нужен для расшифровки данных) никогда не покидает Mary Jane. Хотя тут есть 2 момента. Поскольку самоподписанные сертификаты не имеют централизованного издателя, при большом количестве таких сертификатов появляется вопрос доверия к таким сертификатам:

1. Самое простое — игнорировать ворненги ошибок сертификатов. В таком случае можно надурить отправителя и подсунуть поддельный и недоверенный сертификат. Если вы игнорируете ворненги — вы ССЗБ. Против этого метода защиты не существует.
2. Чуть сложнее — все сертификаты участников обмена шифрованными данными устанавливать в Trusted Root CAs. Тогда ворненгов и не будет. Но при большом количестве таких сертификатов можно ошибочно установить поддельный сертификат к себе в хранилище. И тогда вы будете доверять сертификату злоумышленника.

Следовательно, чисто технически очень сложно организовать атаку MiTM даже с самоподписанными сертификатами. Единственное на что можно рассчитывать — на человеческий фактор. А против человеческого фактора защиты нет никакой. Разве что его можно попытаться снизить за счёт использования централизованного доверенного издателя (центр сертификации). В таком случае придётся установить только один корневой сертификат в Trusted Root CAs. И если сертификат у какого-то участника обмена ВНЕЗАПНО стал недоверенным, можно с определённой уверенностью сказать, что это поддельный сертификат. Но, как я уже отмечал, оба вышеупомянутых пункта относятся как к самоподписанным сертификатам, так и к сертификатам выпущенных централизованным издателем.

Примечание: данный пост содержит зашкаливающее количество НЕНАВИСТИ.

Нетематический пост.

В последнее время у меня появляется всё больше и больше поводов для ненависти по отношению к продуктам Microsoft. Я зачастую вообще не понимаю их. В этом посте я попробую расписать моменты, которые вызывают у меня люто-бешеную ненависть:

• Live Messenger — пустое окно

Иногда при открытии окна Live Messenger видишь пустой список, как здесь:

Я сейчас пруфпиков доставить не могу, потому что это проявляется рандомно и примерно раз в 2-3 недели, но доставил их из интернетов. Лечится только перезапуском мессенджера и закрытием всех окон уютненьких чЯтиков. НЕНАВИСТЬ!

Но частенько его перезапуск выливается в:

• Live Messeger — отсутствие окна

да. Запускаешь Live Messenger и ничего не видишь. В процессах висит, а окна нет. Причём, если запустить ещё раз, начинают плодиться процессы, но окна мессенджера как не было видно, так и не видно. Лечится перелогоном и закрытием всех окон в текущей сессии. НЕНАВИСТЬ!

• Live Messenger — отсутствие автопрокрутки и анимированных смайликов в RDP сессии

иногда при логоне через терминал в активную сессию, ВНЕЗАПНО смайлики перестают быть анимированными. И если в чате кто-то что-то пишет, автоскрол нихрена не работает, даже ролик на мышке не спасает. Приходится использовать scroll bar и вручную его тягать.

• Internet Explorer 8 — залипание кнопок Вперёд/назад/refresh

вообще непостижимая вещь, которая проявляется у меня на нескольких машинах. В процессе работы в браузере ВНЕЗАПНО отваливаются кнопки перелистывания хистори и рефреша страницы (которая находится в конце адресной строки). Они визуально нажимаются, но ничего не делают. Дополнительно, больше не представляется возможным посмотреть на сертификат при посещении HTTPS. Просто закрытие IE ничего не даёт, поскольку ещё остаются процессы iexplore.exe и их нужно явно завершать через Task Manager, taskkill, Stop-Process (что вам больше по душе). Только после убиения всех процессов iexplore.exe и переоткрытием IE нормальная работа восстанавливается на некоторое время. Причём, залипание воздействует как на IEx86, так и на IEx64 одновременно. Предположительно, это проявляется из-за не совсем корректных Java-скриптов на странице. НЕНАВИСТЬ!

• Internet Explorer 8 — восстановление табов

я использую Internet Explorer 64-bit и Internet Explorer 32-bit. Первый использую для повседневного серфинга и всего остального. Второй использую только когда надо пофапать на флешки (которые Adobe Flash). И, как вам должно быть известно, в IE есть функция восстановления табов:

Случается такая вещь, когда у меня одновременно открыты какие-то табы в IEx64 и в IEx86 и их нужно закрыть (например, выполнить рестарт, перелогон или перезапустить IE из-за залипших кнопок). Поскольку IEx64 нельзя сделать дефолтным бразуером (а какого хрена? Мне наоборот хочется, чтобы 64-битный браузер был бы дефолтным), кнопка Reopen Last Browsing Session восстановит случайным образом только что-то одно: табы из IEx64 или IEx86. По моим наблюдениям, в 80% случаев восстанавливаются табы из IEx86 и только в 20% из IEx64. Где там логика — непонятно. Но последовательность закрытия окон IE ни на что ровным счётом не влияет (во всяком случае мне не удалось её выявить). И это доставляет просто огромное количество НЕНАВИСТИ!

• два монитора и RDP

у меня есть типа сервер под управлением Windows Server 2008 R2, к которому подключено 2 монитора. Работая в интерактивной сессии я раскидываю окна по мониторам так, как мне надо. Я почти никогда не выполняю логофф, а просто блокирую станцию через Win + L. Потом когда я подключаюсь к этому серверу с нотебука через RDP, первый монитор всегда масштабируется под размеры экрана нотебука и приложения из второго монитора тоже. Но не все приложения со второго монитора масштабируются корректно. Некоторые просто как висели на втором мониторе, так и остаются (т.е. я вижу на таскбаре окно конкретного процесса, но самого окна не вижу, потому что оно находится за пределами монитора. Есть мнение, что этому подвержены лишь устаревшие приложения. Это доставляет НЕАНАВИСТИ!

А есть ещё другая особенность двух мониторов. Выходя из интерактивной консольной сессии, создаю новую сессию через RDP и продолжаю работать дальше. Когда работу закончил, просто отключаюсь от терминала и всё. И если снова подключиться к интерактивной консольной сессии, мониторы могут случайным образом поменяться местами. Т.е. он как-то рандомно раскидывает приложения по мониторам и всё.

• Outlook 2010 — интерфейс

Ну тут разговор вообще короткий. По сравнению с образцово-показательным интерфейсом Outlook 2007 — это просто убожество и ТВТМ. Это нужно быть Microsoft'ом, чтобы просрать такой замечательный интерфейс и вместо него подложить какую-то студенческую поделку от которой тошнит сильнее, чем от БсСЛ (Бабы с Сайта Лицензирования. Советую посмотреть русскоязычную страничку по лицензированию на сайте Microsoft). Ну, это, наверное, мои личные впечатления, но это интерфейс не для людей, а для каких-то фриков. Даже такой интерфейс мне кажется всяко красивее, чем оригинальный:

Интерфейс аутлука доставляет мне тонны НЕНАВИСТИ каждые 10-20 минут.

А ещё в аутлуке есть специальные папки Deleted Items и Drafts:

Ещё начиная с Outlook 2003 они у меня были всегда в самом верху, что было достаточно удобно и не отвлекало лишний раз. С установкой Outlook 2010 эти папки переехали в середину, между Inbox'ом и Junk e-mail'ом. Причём при переключении между интерактивной консольной сессией и RDP, эти папки иногда перемещаются в самый верх (как это было в Outlook 2007) и потом обратно в середину. Чем это вызвано — непонятно.

• Outlook 2010 — RSS

я много слышал о том, что аутлук — не самое лучшее приложение в качестве RSS-ридера. До некоторого времени я для RSS использовал Windows Live Mail, который меня всем устраивал как RSS-ридер. В связи с планами MS'а по закрытию ньюс-групп (это вторая причина, почему я использовал WLM), я решил отказаться от WLM и перетащить все RSS'ы в аутлук. В принципе, миграция прошла весьма успешно, но аутлук иногда забывает, какие посты он уже скачал через RSS и начинает их качать по новой, в результате чего образуется несколько совершенно идентичных постов в RSS. Причём, он даже может забыть не конкретный пост, а целый блог, перекачивая его то целиком, то частями. Вобщем, согласен, что аутлук — плохой и негодный RSS-ридер. Но альтернатив особо нет, поскольку устанавливать отдельное приложение только ради RSS я не хочу. Лучше буду плакать, колоться, но продолжать жрать кактус (т.е. использовать аутлук), что доставляет НЕНАВИСТЬ!

итоги: меня не покидает ощущение, что MS взял курс "создавать приложения не для людей". Я ещё давно говорил, что MS должен смотреть на команду Live в отношении создания нормальных и удобных интерфейсов, поскольку хороших интерфейсов MS выпускает всё реже и реже. Например, блоги TechNet и MSDN. Как известно, MS'овские бложики работают на Telligence Server (бывший Community Server). Дефолтная тема этого блога весьма простая, но, в то же время, достаточно удобная. И с неделю или две назад, MS запилил новую тему для этих бложеков под стать интерфейсу библиотек MSDN и TechNet. Когда я увидел это убожество, немедленно доставил целый грузовик шлакоблоков. Это вторая полезность RSS — не видишь никакого интерфейса, только необходимый контент.

Можете считать это это-постом, но я вижу, как MS сознательно уродует свои продукты, которые весьма и весьма неплохи.

Примечание: данный пост содержит сведения об изменении настроек Active Directory и Certification Authority и автор ещё раз обращает ваше внимание на дисклаймер данного блога.

---

Иногда при миграции CA принимают решение об отказе в поддержке предыдущей PKI. Это обычно вызвано различными причинами. Например, некорректные и непоправимые ошибки в первоначальной конфигурации CA, неумение правильно провести миграцию, необходимость переконфигурации CA, которая требует создания нового CA и т.д. В таких случаях обычно поступают так:

• параллельно устанавливают ещё один CA и удаляют старый. При этом сертификаты предыдущего CA не поддерживаются и просто выводятся из обращения (как правило с ними ничего не происходит, а только перестают работать, поскольку CA больше не публикует CRL'ы и проверки таких сертификатов проваливаются). Такой метод применяют, когда количество сертификатов выданных прежним CA невелико и им можно пренебречь и переиздать сертификаты.
• параллельно устанавливается ещё один CA, делают кросс-сертификацию старого CA и удаляют его. При этом сертификаты предыдущего CA поддерживаются и используются в работе. В виду отсутствия предыдущего CA, необходимо дополнительно обеспечить успешную валидацию всех ранее выданных сертификатов.

Если первый метод достаточно прост и тривиален, второй уже требует дополнительных действий со стороны администратора. Это публикация CRL при фактическом отсутствии упразднённого CA и поддержание CRT файлов для построения цепочек сертификатов. И в данном случае старая PKI будет частью новой PKI за счёт кросс-сертификации. Для начала нужно рассмотреть что такое кросс-сертификация. Кросс-сертификация — процесс заверения одной иерархией PKI другой иерархии PKI. При этом заверенная PKI будет являться частью завереямой PKI. Рассмотрим простой пример:

Имеется иерархия CA из корневого Contoso-CA1 и подчинённого Contoso-CA2. Вы создаёте новую иерархию, состоящую из Adatum-CA1 и Adatum-CA2. При этом вы можете сделать кросс-сертификацию между Adatum-CA2 и Contoso-CA1 или Contoso-CA2:

В первом случае цепочка сертификатов для сертификата выпущенного в Contoso-CA2 будет выглядеть так:

Adatum-CA1
        Adatum-CA2
                Contoso-CA1
                        Contoso-CA2
                                EndCert

Как видите, клиент не должен явно доверять Contoso-CA1, а только Adatum-CA1. За счёт кросс-сертификации цепочка будет начинаться в иерархии Contoso и заканчиваться в иерархии Adatum.

Во втором случае цепочка сертификатов для сертификата выпущенного в Contoso-CA2 будет выглядеть так:

Adatum-CA1
        Adatum-CA2
                Contoso-CA2
                        EndCert

В принципе, можно сделать ещё и вот так:

В первом случае цепочка сертификатов для сертификата выпущенного в Contoso-CA2 будет выглядеть так:

Adatum-CA1
        Contoso-CA1
                Contoso-CA2
                        EndCert

Во втором случае цепочка сертификатов для сертификата выпущенного в Contoso-CA2 будет выглядеть так:

Adatum-CA1
       Contoso-CA2
               EndCert

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

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

Подготовка шаблонов сертификатов

1. Войдите в систему с правами Enterprise Admins.
2. Нажмите Start, Run… и введите 'MMC'. Если появится диалоговое окно UAC, подтвердите запуск консоли.
3. В меню File нажмите Add/Remove Snap-ins.
4. В списке выберите Certificate Templates, нажмите Add и нажмите Ok для завершения операции.
5. В открывшейся оснастке найдите стандартный шаблон User. Нажмите правой кнопкой на нём и выберите Duplicate Template. Если появится запрос о выборе версии шаблона укажите Windows Server 2003 Enterprise и нажмите Ok.
6. Во вкладке Properties of New Tamplate укажите новое название шаблона. Например, Cross-signing.
7. Снимите галочку с Publish certificate in Active Directory.
8. Во вкладке Request Handling можете указать другой CSP, если, например, хотите хранить сертификат на смарт-карте (рекомендуется).
9. В Issuance Requirements можете указать требование явного одобрения запроса со стороны администратора CA.
10. Во вкладке Extensions выделите Application Policies и нажмите Edit.
11. Удалите всё из списка, после чего нажмите Add и выберите Qualified Subordination. Нажмите Ok.
12. Во вкладке Security удалите всех из разрешений, кроме глобальной или универсальной группы, которой будет разрешено энролить сертификаты для подписи запросов кросс-сертификации.
13. Нажмите Ok для сохранения изменений и записи шаблона в Active Directory.

Теперь нужно добавить нужные шаблоны в выдачу на CA. Для этого:

1. Войдите на сервер CA с именем Adatum-CA2 с правами Enterprise Admins.
2. Нажмите Start, Administrative Tools и нажмите Certification Authority.
3. Выделите секцию Certificate Templates и в контекстном меню выберите New –> Certificate Template to issue.
4. В списке выделите только что созданный Cross-signing и Cross Certification Authority и нажмите Add.

Теперь запросите сертификат на основе шаблона Cross-signing. Этот сертификат вам потребуется для подписывания запросов сертификатов на основе шаблона Cross Certification Authority.

Создание кросс-сертификата

Кросс-сертификация — это весьма обширная тема. Для нашего сценария нет необходимости рассматривать подробности т.н. qualified subordination, поэтому ограничимся самым простым вариантов без дополнительных ограничений. Для этого создайте текстовый файл с именем Policy.inf и следующим содержанием:

[Version]
Signature = $WindowsNT$

[RequestAttributes]
CertificateTemplate = CrossCA

далее скопируйте сертификат CA Contoso-CA2 на локальный диск. Запустите командную строку и выполните следующую команду:

certreq –policy

В открывшемся диалоговом окне укажите файл сертификата Contoso-CA2 и нажмите Open. Во втором диалоговом окне укажите созданный файл policy.inf и нажмите Open. После чего появится окно выбора сертификата подписи. После указания сертификата подписи нажмите Ok и укажите путь размещения и имя запроса сертификата. После чего выполните следующую команду:

certreq –submit path\cross.req

где path\cross.req — путь размещения и имя файла запроса для кросс-сертификата. Если появилось диалоговое окно выбора сервера CA, выберите тот, в выдаче которого находится шаблон Cross Certification Authority и нажмите Ok.

1. Войдите на сервер CA с именем Adatum-CA2 с правами Enterprise Admins и администратора CA.
2. Нажмите Start, Administrative Tools и нажмите Certification Authority.
3. Выделите секцию Pending Requests, найдите в списке самый последний запрос и в контекстном меню выберите Issue. Предварительно вы можете убедиться, что запрос получился корректный и все данные в нём правильные.
4. Перейдите в секцию Issued Certificates, найдите самый последний сертификат (должен быть наш кросс-сертификат) и экспортируйте его в CER файл.

если открыть сертификат и посмотреть вкладку Certification path, можно увидеть, что цепочка этого сертификата заканчивается не на Contoso-CA1, а на Adatum-CA1. Следовательно, для данного сертификата доверие, да и наличие самого Contoso-CA1 уже не обязательно.

На данном этапе остался последний шаг — публикация кросс-сертификата в Active Directory. Для этого запустите командную строку с повышенными привилегиями (выбрав Run as administrator в контекстном меню значка Command Prompt) и выполните в ней следующую команду:

certutil –dspublish –f path\cross.cer

где path\cross.cer — путь размещения и имя файла кросс-сертификата.

Подготовка к демонтажу старых центров сертификации

Прежде чем демонтировать ненужные центры сертификации, необходимо переподписать все их CRL и поместить их в точки публикации CDP, например, LDAP и/или веб-сервер. Для этого вы должны зайти на каждый демонтируемый сервер CA и выполнить следующую команду:

cd c:\windows\system32\certsrv\certenroll\
certutil –sign .crl 1.crl now+1825:00
certutil –sign +.crl 1+.crl now+1825:00

Certutil –sign переподпишет старые CRL'ы с новым более долгим сроком, в нашем случае — на 5 лет. Т.е. эти CRL'ы будут действительны последующие 5 лет. Далее, вы должны скопировать эти CRL'ы в точки публикации. При этом следует удалить единички (которые были добавлены только для создания нового файла) из имён файлов, чтобы они совпадали с именами файлов в расширениях сертификатов.

Демонтаж старых центров сертификации

Демонтаж старых центров сертификации следует проводить в соответствии с этим руководством: How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003 and from Windows Server 2000

Примечание: удалять следует только объекты относящиеся демонтируемым центрам сертификации. В противном случае вы можете удалить и объекты новых действующих CA.

Недавно в мессенджер упал интересный вопрос:

в Active Directory у пользователя есть атрибут msRADIUSFramedIPAddress в котором храниться статический IP адрес, который назначается на вкладке Dual In в свойствах пользователя. Если смотреть через LDAP то значение мало похоже на введённый IP адрес. Хотелось бы на выходе получить работающий скрипт пишущий в файл соответсвие пользователь - IP адрес. Как я понял проблему, идёт двойная конвертация.

Действительно, если смотреть на это свойство через провайдер ADSI (не путать с adsiedit.msc), мы увидим число мало похожее на IP адрес. Например, 168846386. Для приведения данного числа в формат IP адреса нужно преобразовать его в двоичный формат, а после — разбить на октеты по 8 бит и каждый октет преобразовать обратно в десятичную форму. В .NET есть целый класс конверторов System.Convert, который позволяет конвертировать между собой множество форматов. Мы воспользуемся вот таким методом: Convert::ToString Method (Int32, Int32), в котором первый аргумент отвечает за исходное число, а второй — выходной формат. Поскольку нам нужно получить двоичное представение, указываем формат 2:

[↓] [vPodans] [convert]::ToString(168846386,2)
1010000100000110010000110010

Строка содержит неполные 32 бита. Чтобы их дополнить мы должны добавить слева недостающие нули:

[↓] [vPodans] $bin = [convert]::ToString(168846386,2)
[↓] [vPodans] $bin
1010000100000110010000110010
[↓] [vPodans] $bin.length
28
[↓] [vPodans] $fullBin = "0" * (32 - $bin.length) + $bin
[↓] [vPodans] $fullbin
00001010000100000110010000110010

Мы знаем, что 4 октета это 32 бита, следовательно вычитаем из 32 длину актуальной строки и получаем количество добавочных нулей. И эти нули добавляем в начало строки. Теперь эту строку надо разбить на 4 октета по 8 бит или по 1 байту:

[↓] [vPodans] 0,8,16,24 | %{$fullbin.substring($_,8)}
00001010
00010000
01100100
00110010

Я воспользовался методом String::Substring Method (Int32, Int32). Первый аргумент указывает стартовый символ, откуда начинать вырезать, а второй аргумент указывает количество символов, которые нужно вырезать. Вот и получили 4 байта. Преобразовать обратно в десятичный формат их так же просто, но с использованием Convert::ToInt32 Method (String, Int32):

[↓] [vPodans] 0,8,16,24 | %{[convert]::ToInt32($fullbin.Substring($_,8),2)}
10
16
100
50

Теперь это осталось собрать в строку и расставить точки между октетами. Для этого мы вопспользуемся статическим методом Join() класса System.String:

[↓] [vPodans] [string]::Join(".",$(0,8,16,24 | %{[convert]::ToInt32($fullbin.substring($_,8),2)}))
10.16.100.50

вот мы и получили наш заветный IP-адрес. И вот весь код:

$bin = [Convert]::ToString(168846386,2)
$fullBin = "0" * (32 - $bin.Length) + $bin
[string]::Join(".", $(0,8,16,24 | %{[Convert]::ToInt32($fullBin.Substring($_,8),2)}))

Надеюсь, поможет ещё кому-нибудь :-)

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

 

 

Q: Как узнать тип установленного на сервере Certification Authority?

A: тип Certification Authority можно узнать несколькими методами, которые обычно основываются на реестре:

HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CA Sanitized Name>

и запись типа REG_DWORD — CAType. И вот что означает каждое значение:

0 — Enterprise Root CA
1 — Enterprise Subordinate CA
3 — Standalone Root CA
4 — Standalone Subordinate CA
5 — Unknown

По большому счёту, если вы задаёте этот вопрос, значит, для вас этот тип — Unknown (5) :-)

Q: Может ли в домене/лесу Active Directory существовать 2 и более иерархий PKI с разными корневыми центрами сертификации?

A: да, вы можете в существующем домене/лесу развернуть несколько независимых иерархий PKI. Сервер CA не использует домен для захвата власти, а только лишь для обеспечения удобства распространения и выдачи сертификатов конечным потребителям.

Q: Можно ли мигрировать сервер CA с платформы x86 на x64? Судя по этой статье: http://support.microsoft.com/kb/298138, это невозможно. Как быть?

A: Сведения представленные в указанной статье не совсем достоверны. Технически бэкап БД выполненный на платформе x86 может быть успешно восстановлен на платформе x64 и каких-то проблем с этим возникнуть не должно. Поэтому вы можете смело планировать миграцию ваших серверов CA с x86 на x64, особенно если существующий CA работает на системе под управлением Windows 2000. В качестве руководства по миграции вы можете руководствоваться следующим вайтпепером: http://technet.microsoft.com/en-us/library/ee126170(WS.10).aspx

Q: Я зашифровал папку с файлами при помощи EFS, но пользователи всё равно могут просматривать содержимое папки? Что это, баг или данные просто не шифруются?

A: Это не баг, а нормальное поведение системы (при условии, что другие пользователи имеют права на просмотр содержимого каталога). Если посмотреть на файловую сисему изнутри, становится понятно, что папка — всего лишь логический контейнер и он хранится в MFT. Папка сама по себе не содержит в себе данных и не имеет размера. А сами данные, которые нужно шифровать находятся в другой части файловой системы. Поэтому если вы зашифровали папку средствами EFS, шифруются сами данные, но обзор списка файлов в шифрованной папке по прежнему разрешён.

Q: мне нужно издать сертификат с некоторыми данными в расширении Subject Alternative Name (SAN). Я создаю запрос с этим расширением, но CA игнорирует это расширение. Как быть?

A: по умолчанию Windows CA игнорирует это расширение в целях безопасности. Для включения этого расширения воспользуйтесь сведениями из этой статьи: http://support.microsoft.com/kb/931351

Q: для чего служат различные контейнеры в AD внутри контейнера Public Key Services?

A: эти контейнеры служат для обеспечения автоматизации работы центра сертификации, подачи запросов и проверки сертификатов.

• NTAuthCertificates — служит для хранения сертификатов центров сертификации, которым разрешено издавать логонные сертификаты (для смарт-карт, для аутентификации по сертификатам в VPN или IIS) для текущего леса. Например, вы используете сторонний центр сертификации, выдающий сертификаты для смарт-карт. Для того, чтобы контроллеры домена распознавали и доверяли этим сертификатам, сертификат стороннего CA должен быть добавлен в NTAuthCertificates. Сертификаты из этого контейнера автоматически копируются доменными клиентами при обновлении групповых политик и помещаются в контейнер Intermediate CAs.
• AIA — служит для хранения сертификатов центров сертификации. Сертификаты из этого контейнера используются для ускорения построения цепочек сертификатов при проверке. Сертификаты из этого контейнера автоматически копируются доменными клиентами при обновлении групповых политик и помещаются в контейнер Intermediate CAs.
• CDP — служит для хранения списков отзыва (Certificate Revocation List или CRL). Списки отзыва используются для определения статуса конкретного сертификата (отозван или не отозван). CRL'ы из этого контейнера не копируются клиентами. Поэтому CRL опубликованный в данном контейнере может быть использован только если расширение CDP какого-то сертификата явно ссылается на него.
• Certifiation Authorities — служит для хранения собственных или сторонних доверенных корневых центров сертификации. Сертификаты из этого контейнера автоматически копируются доменными клиентами при обновлении групповых политик и помещаются в контейнер Trusted Root CAs.
• KRA — служит для хранения выпущенных сертификатов агентов восстановления. Каждый выпущенный сертификат агент восстановления публикуется в этот контейнер в запись соответствующего CA. Важно понимать, что при назначении нового агента восстановления на сервере CA, содержимое данного контейнера не изменяется.
• Enrollment Services — служит для хранения записей и сертификатов всех Enterprise CA в текущем лесу. Клиенты используют этот контейнер для обнаружения Enterprise CA.
• OID — содержит все OID'ы зарегистрированные в вашей компании. В том числе  Issuance, Application Policies, Certificate Templates OID's.
• Certificate Templates — служит для хранения сведений о всех шаблонах сертификатов текущего леса.

Q: я создал шаблон версии 3 (Windows Server 2008 Enterprise Edition) для смарт-карт, но при энроллменте я получаю ошибку. В чём дело?

A: исторически CSP (Cryptography Service Provider) смарт-карт не поддерживают алгоритмы CNG (Cryptography New Generation), которые реализованы в шаблонах версии 3. Следовательно, вы не можете использовать шаблоны версии 3 для смарт-карт. Вместо этого вы должны использовать шаблоны версии 2 (Windows Server 2003 Enterprise Edition).

Q: я установил MS OCSP Responder, но папка веб-приложения пуста. Что должно быть в папке OCSP?

A: Имплементация OCSP в Windows основывается на ISAPI фиьтрах, реализованных в библиотеке ocspisapi.dll. Поэтому при создании веб-приложения OCSP путь к нему указывается как %systemroot%\SystemData\ocsp. В этой папке есть только папка aspnet_client, но файлов никаких нет. Их быть и не должно.