none
SP1 и сертификаты от корпоративного ЦС RRS feed

  • Вопрос

  • Давно пользуемся сертификатами от корпоративного ЦС, в том числе на домашних системах.

    То есть - импортируем дома персональный сертификат, выданный корпоративным ЦС, сертификат корневого корпоративного ЦС помещаем в "Доверенные корневые центры", сертификат выдающего в "Промежуточные центры сертификации".

    Дальше пользуемся доступом к корпоративным ресурсами по SSL без выдачи предупреждений о недействительности сертификата, EAP для аутентификации при РРТР-подключении, плюс SSTP после выхода 2008 сервера.

    После установки SP1 перестало работать всё. Попытки подключения SSTP заканчиваются "Ошибка: 0х80096004: нельзя проверить подпись сертификата". Попытки использования IE для доступа к корпоративным ресурсам по SSL - "Internet Explorer не может отобразить эту веб-страницу". То есть - не то, что б запрос-предупреждение выдавался - нет доступа никак. Через альтернативные браузеры всё работает без проблем, как и раньше.

    Ситуацию получил на двух системах со свежеустановленным SP1. А проверять начал после обращения коллег, установивших SP1, с вопросом - "почему у нас пропал доступ?".

    Что попробовал - сертификаты своих CA скопировать во все возможные места :) - "Сторонние корневые центры сертификации", "Доверенные издатели"... и не только компьютера, но и пользователя. Не помогает.

    Интересно, оно так и задумано?

    Если это by design - то это 3,14здец.


    S.A.
    27 февраля 2011 г. 19:45

Ответы

  • ... Поэтому предполагается выбрать одни из грядущих длинных выходных, установить новый корневой ЦС, перевыпустить сертификаты подчинённых... с последующим некоторым геммороем :).

    Абыдно, что никакой вменяемой диагностики, ...


    Суть проблемы.

    Когда-то, при установке корневого СА под W2000, его сертификат был сгенерирован с использованием MD-5.

    MS-ом официально было объявлено о прекращении с 2011 года поддержки сертификатов корневых СА, выпущеных с использованием алгоритмов, "хуже" SHA-1.

    Весьма похоже, что "прекращение поддержки" реализовано с выпуском SP1 на уровне кода.

    Новым корневым СА с сертификатом, созданным с использованием правильного алгоритма, проблема решена.

    Большое спасибо сотрудникам "ВЕРИСЕЛ Проекты" и конкретно Андрею Кучинскому за осмысленную диагностику проблемы.


    S.A.
    • Помечено в качестве ответа AndricoRusEditor 25 мая 2011 г. 19:55

Все ответы

  • Давно пользуемся сертификатами от корпоративного ЦС, в том числе на домашних системах.

    То есть - импортируем дома персональный сертификат, выданный корпоративным ЦС, сертификат корневого корпоративного ЦС помещаем в "Доверенные корневые центры", сертификат выдающего в "Промежуточные центры сертификации".

    Дальше пользуемся доступом к корпоративным ресурсами по SSL без выдачи предупреждений о недействительности сертификата, EAP для аутентификации при РРТР-подключении, плюс SSTP после выхода 2008 сервера.

    После установки SP1 перестало работать всё. Попытки подключения SSTP заканчиваются "Ошибка: 0х80096004: нельзя проверить подпись сертификата". Попытки использования IE для доступа к корпоративным ресурсам по SSL - "Internet Explorer не может отобразить эту веб-страницу". То есть - не то, что б запрос-предупреждение выдавался - нет доступа никак. Через альтернативные браузеры всё работает без проблем, как и раньше.

    Ситуацию получил на двух системах со свежеустановленным SP1. А проверять начал после обращения коллег, установивших SP1, с вопросом - "почему у нас пропал доступ?".

    Что попробовал - сертификаты своих CA скопировать во все возможные места :) - "Сторонние корневые центры сертификации", "Доверенные издатели"... и не только компьютера, но и пользователя. Не помогает.

    Интересно, оно так и задумано?

    Видимо, к написанному имеет смысл добавить, что CRL опубликованы и доступны через интернет по http (что легко проверяется обращением браузером по указанному в сертификате url), причём в сертификатах http указан _перед_ ldap.


    S.A.
    28 февраля 2011 г. 11:43
  • Попробовал импортировать вручную списки отзыва, как пользователю, так и в компьютерное хранилище. Не помогло. С соседней системы без SP1 по прежнему всё успешно работает.

    Господа, никто не пользуется ssl, с сертификатами собственных ЦС, для доступа поверх интернет, с компьютеров, не включённых в домен?

    В общем, что бы продолжать пользоваться схемой, используемой десяток лет, придётся или отказаться от IE, или от SP1 для 7-ки, или ... Печально это.


    S.A.
    28 февраля 2011 г. 19:57
  • Я пользуюсь, правда только веб-мордой почтового сервера (крутится на IIS7.5) - всё в норме.

    Поиграйтесь с certutil

    certutil -v -verify you_cer.crt


    Не забывайте отмечать поcты как ответы, а также помечать полезные сообщения!
    1 марта 2011 г. 7:52
  • Я пользуюсь, правда только веб-мордой почтового сервера (крутится на IIS7.5) - всё в норме.

    Поиграйтесь с certutil

    certutil -v -verify you_cer.crt

    Удаляю сертификаты своих ЦС из всех контейнеров всех хранилищ (пользователь, компьютер). Доступ к корпоративным узлам есть - с предупреждением о недействительности сертификата. Результаты проверки сертификата моего корневого ЦС certutil -

    ... Цепочка сертификатов обработана, но обработка прервана на корневом сертификате, у которого отсутствует отношение доверия с поставщиком доверия. 0x800b0109 (-2146762487)
    ------------------------------------
    Проверка через НЕ ДОВЕРЕННЫЙ корень
    Сертификат является сертификатом ЦС
    Проверка отзыва сертификата выполнена
    CertUtil: -verify - команда успешно выполнена.

    - что понятно.

    Добавляю сертификат в "Доверенные корневые ...". IE при попытке доступа к тем же узлам тут же вываливает, что "... не может отобразить эту веб-страницу". Результаты проверки этого же сертификата certutil -

    ... Проверенные политики выдачи: Все
    Проверенные политики применения: Все
    Сертификат является сертификатом ЦС
    Проверка отзыва сертификата выполнена
    CertUtil: -verify - команда успешно выполнена.

    Вот как-то так...


    S.A.
    1 марта 2011 г. 17:35
  • > корневого корпоративного ЦС помещаем в "Доверенные корневые центры", сертификат выдающего в "Промежуточные центры сертификации".

    в пользовательское или компьютерное хранилище?


    http://en-us.sysadmins.lv
    PowerShell PKI module: http://pspki.codeplex.com/
    18 марта 2011 г. 10:17
  • > корневого корпоративного ЦС помещаем в "Доверенные корневые центры", сертификат выдающего в "Промежуточные центры сертификации".

    в пользовательское или компьютерное хранилище?

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


    S.A.

    P.S. Собственно, при добавлении сертификата в компьютерное хранилище и последующем просмотре пользователем "Доверенных корневых ..." в "собственном" хранилище, импортированный сертификат видно и там, только удаление его пользователю недоступно, в отличие от варианта импорта непосредственно этим пользователем в собственное хранилище.

    P.P.S. Эффект получен уже на 5-ти системах, куда установлен SP1.

    19 марта 2011 г. 10:53
  • Можете нам показать файл сертификата SSL?

    И вы смотрели журнал CAPI2? Там должно быть много интересного по вашей проблеме.


    http://en-us.sysadmins.lv
    PowerShell PKI module: http://pspki.codeplex.com/
    20 марта 2011 г. 8:05
  • Можете нам показать файл сертификата SSL?

    Да, собственно, всё показать не проблема. Пытаюсь попадать, например, сюда - https://portal.matfmc.ru - дальше окна логона не пустит, но этого достаточно для просмотра сертификата сервера. Списки отзыва и сертификаты доступны по указанной там информации, в частности, для корневого, "Доступ к информации о центрах сертификации": URL=http://matfsrv.matfmc.ru/CertEnroll/caroot.matfmc.ru_CAROOT(2).crt

    Вот после импорта этого сертификата, под W7 SP1 (или после установки SP1 на систему, где сертификат импортирован и всё работает), пропадает любой доступ. Не только к сайтам, SSTP накрылся, соответственно...

    И вы смотрели журнал CAPI2? Там должно быть много интересного по вашей проблеме.

    Не смотрел. Это где и куда?


    S.A.

    P.S. Из под IE доступ пропадает - огнелис и прочие, использующие собственные механизмы, продолжают попадать куда надо, конечно же...

    24 марта 2011 г. 19:44
  • одну ошибку я уже нашёл:

    у сертификата MATFCA неправильное расширение authority information access. Там есть ссылка на корневой сертификат, только она находится в разделе ссылок для OCSP. Т.е. вам нужно будет поменять сертификат MATFCA, предварительно исправив расширение AIA в настройках корневого CA.

    То же самое и с MATFCA. Т.е. вам нужно исправить конфигурацию расширения AIA на корневом и на MATFCA и переиздать сертификаты.


    http://en-us.sysadmins.lv
    PowerShell PKI module: http://pspki.codeplex.com/
    25 марта 2011 г. 6:49
  • одну ошибку я уже нашёл:

    у сертификата MATFCA неправильное расширение authority information access. Там есть ссылка на корневой сертификат, только она находится в разделе ссылок для OCSP. Т.е. вам нужно будет поменять сертификат MATFCA, предварительно исправив расширение AIA в настройках корневого CA.

    То же самое и с MATFCA. Т.е. вам нужно исправить конфигурацию расширения AIA на корневом и на MATFCA и переиздать сертификаты.

    То есть, если "показывать пальцем" - снять галочку "Включать в расширения протокола OCSP" (Include in the online status certificate protocol (OSCP) extensions), после чего заняться перевыпуском сертификатов?

    Что ж, попробую. Будет занятием на выходные :).

    А почему оно любой системе до W7/2008R2 SP1 работать не мешает?

    P.S. На всякий случай уточнение - оба ЦС под 2003, устанавливались/настраивались когда-то под W2K, в 2005 г. апгрейдились до 2К3.


    S.A.
    25 марта 2011 г. 10:45
  • переставить чекбокс с Include in OCSP extension в Inclide in AIA extension.

     


    http://en-us.sysadmins.lv
    PowerShell PKI module: http://pspki.codeplex.com/
    25 марта 2011 г. 11:56
  • переставить ...
    "Include in the AIA extension ..." имеет место быть, 9 лет как.
    S.A.
    26 марта 2011 г. 9:45
  • да, имеет место быть, только там сслыка на LDAP и извне она недоступна.
    http://en-us.sysadmins.lv
    PowerShell PKI module: http://pspki.codeplex.com/
    26 марта 2011 г. 12:09
  • да, имеет место быть, только там сслыка на LDAP и извне она недоступна.

    Предлагаю попробовать поверить мне на слово - на соответствующей закладке, для соответствующей позиции, были установлены обе галочки (при том, что я благополучно вижу в "старом" сертификате метод доступа только ....48.1 - OCSP, тем не менее).

    Убрать галочку для OCSP и перевыпустить сертификаты попробовал. Результат ... любопытен :).

    Описание доступного сейчас "стенда", имеется: свежеустановленная W7SP1 x64 + IE9 (кроме написанного не ставилось ничего вообще, дистрибутив с интегрированным SP1), на том же железе ХР (альтернативная загрузка), ноут с W7SP1 + IE8, ещё одна W7 + IE8 без SP1. Доступ в корпоративную сеть (к ЦС для настройки) по VPN (PPTP, в связи с ...).

    Сразу про ХР и W7 без SP1 - доступ (как без предупреждений с импортированным сертификатом корневого ЦС, так и без него, с предупреждением и нажатием "продолжить") сохраняется во всех опробованных вариантах, об этом упоминать дальше не буду.

    После перевыпуска сертификатов с отмеченным в настройках только чекбоксом "Inclide in AIA extension" - доступ c всех W7SP1 к приведённому ранее url пропал вообще (назову ситуацию "вариант 2") - вне зависимости от наличия в локальном хранилище сертификата корневого ЦС. НО - несколько по разному :). С ноута (IE8) - немедленно выдаётся "IE не может отобразить эту веб-страницу" - как ранее при наличии импортированного сертификата корневого ЦС. С W7SP1 x64 + IE9 - выдаётся страница предупреждения о невалидности сертификата, но при нажатии продолжить, далее не происходит ничего (точнее, заново выводится эта же страница). После импорта сертификата - та же "диагностика" о недоступности страницы, что и ранее.

    Собственно, выводимая IE "диагностика" соответствует некорректному url. Ещё - коллега, у которого W7 SP1 на достаточно медленном железе, поделился, что успевает заметить проскакивающую в строке состояния информацию об ошибке DNS - невозможности срезольвить "чего-то-там"...

    Когда-то давно, обратил внимание, что в свежеустановленных ЦС в некоторых местах прописаны url cтандартным образом, а в некоторых с использованием тройного слеша (типа http:///...). Тогда конкретной информации об однозначной корректности не нашел, привёл все пути в настройках к стандартному виду (http://...). Сейчас, тупо посмотрев на результаты "вариант 2", решил проверить использование "///" - подредактировал пути к спискам отзыва и информации о центрах сертификации, перевыпустил сертификаты ещё раз. Результат - ситуация вернулась к первому варианту, с возможностью доступа через нажатие "продолжить" при отсутствии импортированного сертификата корневого ЦС (и отсутствием доступа после импорта).

    На данный момент, оставлен последний вариант url (с "///") - предполагаю, что правильно будет именно классический вариант ("//"), но поскольку в таком случае доступа нет вообще, пусть лучше будет неправильно.

    В общем, получить положительного результата, увы, не удалось...


    S.A.
    27 марта 2011 г. 12:32
  • вижу ваш новый сертификат. Ссылки теперь расставлены правильно, но по ним ничего не скачивается. С CRL'ами так же, ссылки есть, а файлов по ним нету.


    http://en-us.sysadmins.lv
    PowerShell PKI module: http://pspki.codeplex.com/
    28 марта 2011 г. 5:34
  • Собственно говоря, трындец.

    С путями к спискам отзывов и сертификатам я внимательно поразбирался, сейчас должно быть всё (кроме ldap) доступно (по моим представлениям) для внешних хостов. Но это ничего не решает, без SP1 доступ есть, с SP1 - доступа нет. IE9 выдаёт страницу предупреждения о недействительности сертификата, при нажатии "продолжить" не происходит ничего (остаётся эта страница). IE8 выдаёт страницу с ошибкой недоступности ресурса (как при пропадании связи).

    А совсем плохо следующее. Я поставил SP1 на экспериментальную (свою) Win 7 в домене. И получил потерю работоспособности PKI предприятия для этой системы. IE9 ведёт себя так же, как описано выше. Outlook не может проверять подписи и расшифровывать. Windows Messenger отказывается соединяться с LCS из-за ошибки TLS. Не устанавливается SSTP соединение. В общем, трындец полный. Ваще.

    При просмотре сертификатов оснасткой "Сертификаты" или проверкой certutil - сертификаты (пользовательский, внутренних сайтов, ЦС) - действительны. "А включаешь - не работает". Любопытно поведение оснастки "PKI предприятия": на 2008R2 SP1 - всё действительно и хорошо, на подопытной Win7 SP1 - все расположения с использованием http недоступны - "Невозможно загрузить".

    Альтернативы - FireFox и прочие - пробелем не имеют. Откат "до SP1" - "проблему" решает (удовольствие - установка/откат SP1 - ещё то, перекурчик часа на полтора).

    Взгляды по сторонам - http://social.technet.microsoft.com/Forums/en-US/w7itprogeneral/thread/6120c17c-d605-46e3-aa23-3e997e51ca8b - свидетельствуют, что я не одинок. Что ж за б...ство такое, а? Куды копать? Вменяемой диагностики - полный ноль...


    S.A.
    23 апреля 2011 г. 18:37
  • ... Любопытно поведение оснастки "PKI предприятия": на 2008R2 SP1 - всё действительно и хорошо, на подопытной Win7 SP1 - все расположения с использованием http недоступны - "Невозможно загрузить". ...


    Из этого моего текста можно подумать, что под 2008 R2 SP1 проблемы нет - отнюдь. Проблема (под R2 SP1) с доступом пользователя на внутренние ресурсы по SSL есть, и проблема коннекта к LCS по TLS тоже. Только оснастка "PKI предприятия" ведёт себя по разному. При этом 2008R2 SP1 в домене уже несколько (ведут себя одинаково), вот W7 SP1 одна. И больше, в обозримом будущем, не предвидится, если только "для макета" понаставить.

    Ещё ноут W7 SP1 по WiFi с использованием пользовательского сертификата коннектицца перестал - не доверяет сертификату УЦ, явно тыкнутому "галочкой"... Но это уже ожидаемо :).

    Бодро занимаюсь перенастройкой всего, что вспомнится :), для исключения криптографии от MS, остальное будем убирать, когда отвалится. Спасибо, Господа, за заботу о повышении безопасности неразумных юзеров, поскольку понятно, что теперь "так" by design :))) (люблю я этот ответ. Грохнули что-то, без чего многие себя плохо чувствуют - by design: или проникайтесь тем, что за вас лучше знают, как вам удобнее, или пнах. Уже всё больше хочется "пнах" :))).

    В общем, спасибо всем, кто прочитал :). Изучив всё, что нашел по проблеме по англицки, и по опыту последних лет, решения не ожидаю.


    S.A.
    24 апреля 2011 г. 16:35
  • Обновил до SP1 пол парка Win7 - ваших проблем не замечено!

    Советую вам хорошо отдохнуть, а потом снова проверить ВСЁ, причём отбросив все предыдущие результаты и мысли. Помогает!


    Не забывайте отмечать поcты как ответы, а также помечать полезные сообщения!
    26 апреля 2011 г. 23:54
  • :) дык понятно, что если бы эти проблемы были у всех, кто ставит SP1, шуму было бы си-ильно много...

    А мысль пока одна... Году, эдак, в 2005, я "исследовал" подведение The Bat при работе с MIME Security. У бата есть два варианта - использование собственной встроенной криптографии, или использование системной (от MS). Так вот, при попытках заставить работать первый вариант, он (бат) категорически заявлял, что мой сертификат корневого ЦС не может являться действительным сертификатом корневого ЦС. Работало оно только при использовании MS-криптографии (частично работало, но там другие заморочки, уже не связанные с доверием ЦС). Тогда я предположил, что проблема в множестве незаполненных полей созданного "почти по умолчанию" сертификата нашего корневого ЦС (в 2001 году, когда это изначально делалось, информации по теме и опыта было маловато). Поэтому предполагается выбрать одни из грядущих длинных выходных, установить новый корневой ЦС, перевыпустить сертификаты подчинённых... с последующим некоторым геммороем :).

    Абыдно, что никакой вменяемой диагностики, с точки зрения оснасток и certutil все сертификаты валидны, и - не работает. Единственное, что есть в логах - при попытке коннекта WM (или lync) два сообщения в System от Schannel (36888 и 36876) - "Сертификат, полученный от удаленного сервера, не прошел проверку. Код ошибки: 0x80096004. Запрос на SSL-соединение не удалось выполнить" - но это уже очевидно следствие, а не причина.


    S.A.
    27 апреля 2011 г. 7:56
  • ваша ошибка говорит о том, что: The signature of the certificate cannot be verified. Вот и думайте.


    My weblog: http://en-us.sysadmins.lv
    PowerShell PKI Module: http://pspki.codeplex.com
    27 апреля 2011 г. 10:02
  • Вроде как над этим и думаю. Поскольку на "подпись сертификата не может быть проверена" достаточно любовался в разнообразных вариантах. Например, при попытке подключения по SSTP этот текст выдаётся непосредственно (кроме кода ошибки в логи). И нисколько не сомневаюсь, что "сертификат ... не прошел проверку" потому что "подпись не может быть проверена".

    Может подскажете, куда думать, что б определить, почему без SP1 всегда verified, с SP1 - certutil и оснасткой Сертификаты тоже verified, а при установке соединения - не verified?

    P.S. Убедительная просьба :). Конечно же, случается, что "замыленным глазом" я не замечаю очевидных вещей, но как правило, воспользоваться MSKB (и даже eventid :)) удаётся успешно. И когда "с нетерпением" лезешь в свою тему прочитать новенькое, а видишь то, про что поленился написать "да, и это я знаю", считая очевидным... бывает немножко обидно :). Поэтому классическое "Спасибо за то, что отвечаете", а если моя (предшествующая) реакция покажется не совсем корректной, просьба не обращать внимания :).


    S.A.
    27 апреля 2011 г. 12:26
  • В процессе раздумий обнаружил ещё косячок - в capolicy, при установке корневого ЦС, не было добавлено секции [AuthorityInformationAccess] Empty=true, в результате его сертификат содержал ссылку для доступа к самому себе. Поправил. Перевыпустил "минимально необходимые" для проверки сертификаты.

    Не помогло...


    S.A.
  • ... Поэтому предполагается выбрать одни из грядущих длинных выходных, установить новый корневой ЦС, перевыпустить сертификаты подчинённых... с последующим некоторым геммороем :).

    Абыдно, что никакой вменяемой диагностики, ...


    Суть проблемы.

    Когда-то, при установке корневого СА под W2000, его сертификат был сгенерирован с использованием MD-5.

    MS-ом официально было объявлено о прекращении с 2011 года поддержки сертификатов корневых СА, выпущеных с использованием алгоритмов, "хуже" SHA-1.

    Весьма похоже, что "прекращение поддержки" реализовано с выпуском SP1 на уровне кода.

    Новым корневым СА с сертификатом, созданным с использованием правильного алгоритма, проблема решена.

    Большое спасибо сотрудникам "ВЕРИСЕЛ Проекты" и конкретно Андрею Кучинскому за осмысленную диагностику проблемы.


    S.A.
    • Помечено в качестве ответа AndricoRusEditor 25 мая 2011 г. 19:55