Пакет был подписан сертификатом срок годности которого истек mac

Обслуживание клиентов Mac

Начиная с января 2022 г. эта функция Configuration Manager является устаревшей. Дополнительные сведения см. в статье Компьютеры Mac.

Ниже приведены процедуры по удалению клиентов Mac и обновлению их сертификатов.

Удаление клиента Mac

1. На компьютере Mac откройте окно терминала и перейдите к папке, содержащей macclient.dmg.
2. Перейдите в папку Сервис и введите следующую командную строку: ./CMUninstall -c

Примечание. Свойство -c указывает, что удаление клиента также удаляет журналы сбоев клиента и файлы журналов. Мы рекомендуем это сделать, чтобы избежать путаницы при последующей переустановке клиента.

Обновление сертификата клиента Mac

Используйте один из следующих методов, чтобы обновить сертификат клиента Mac:

• Мастер обновления сертификатов
• Продление сертификата вручную

Мастер обновления сертификатов

1. Настройте следующие значения в виде строк в файле ccmclient.plist, который управляет при открытии мастера обновления сертификатов:
   • RenewPeriod1 — указывает в секундах первый период продления, в течение которого пользователи могут продлить сертификат. Значение по умолчанию — 3 888 000 секунд (45 дней). Не настраивайте значение меньше 300, так как период будет отменить изменения по умолчанию.
   • RenewPeriod2 — указывает в секундах второй период продления, в течение которого пользователи могут продлить сертификат. Значение по умолчанию — 259 200 секунд (3 дня). Если это значение настроено и больше или равно 300 секундам и меньше или равно Параметру RenewalPeriod1, будет использоваться значение . Если параметр RenewalPeriod1 превышает 3 дня, для параметра RenewalPeriod2 будет использоваться значение 3 дня. Если параметр RenewalPeriod1 составляет менее 3 дней, то параметр RenewalPeriod2 имеет то же значение, что и RenewalPeriod1.
   • RenewReminderInterval1 — указывает в секундах частоту, с которой мастер продления сертификатов будет отображаться для пользователей в течение первого периода продления. Значение по умолчанию — 86 400 секунд (1 день). Если параметр RenewalReminderInterval1 превышает 300 секунд и меньше значения, настроенного для RenewalPeriod1, будет использоваться настроенное значение. В противном случае будет использоваться значение по умолчанию 1 день.
   • RenewReminderInterval2 — указывает в секундах частоту, с которой мастер продления сертификатов будет отображаться для пользователей в течение второго периода продления. Значение по умолчанию — 28 800 секунд (8 часов). Если значение RenewalReminderInterval2 больше 300 секунд, меньше или равно Значению RenewalReminderInterval1 и меньше или равно RenewalPeriod2, будет использовано настроенное значение. В противном случае будет использоваться значение 8 часов. Примере: Если значения остаются по умолчанию, за 45 дней до истечения срока действия сертификата мастер будет открываться каждые 24 часа. В течение 3 дней после истечения срока действия сертификата мастер будет открываться каждые 8 часов. Примере: Используйте следующую командную строку или скрипт, чтобы задать для первого периода продления 20 дней. sudo defaults write com.microsoft.ccmclient RenewalPeriod1 1728000
2. Когда откроется мастер продления сертификатов, поля Имя пользователя и Имя сервера обычно заполняются заранее, и пользователь может просто ввести пароль для продления сертификата.

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

Продление сертификата вручную

Обычно срок действия сертификата клиента Mac составляет 1 год. Configuration Manager не обновляет автоматически сертификат пользователя, запрошенный во время регистрации, поэтому для продления сертификата вручную необходимо выполнить следующую процедуру.

Если срок действия сертификата истек, необходимо удалить, переустановить и повторно зарегистрировать клиент Mac.

Эта процедура удаляет ИДЕНТИФИКАТОР SMS, необходимый для запроса нового сертификата для того же компьютера Mac. При удалении и замене ИДЕНТИФИКАТОРа SMSID клиента все сохраненные журналы клиентов, такие как инвентаризация, удаляются после удаления клиента из консоли Configuration Manager.

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

Предупреждение Configuration Manager не отслеживает срок действия сертификата, зарегистрированного для компьютеров Mac. Необходимо отслеживать это независимо от Configuration Manager, чтобы определить компьютеры Mac для добавления в эту коллекцию.

• Имя:удаление SMSID для Mac
• Тип:Mac OS X

• Имя:удаление SMSID для Mac
• Тип параметра:Скрипт
• Тип данных:String

defaults read com.microsoft.ccmclient SMSID 

defaults delete com.microsoft.ccmclient SMSID 

• Имя:удаление SMSID для Mac
• Выбранный параметр: Нажмите кнопку Обзор , а затем выберите сценарий обнаружения, указанный ранее.
• В следующем поле значений введите Пара домен/по умолчанию (com.microsoft.ccmclient, SMSID) не существует.
• Включите параметр Запуск указанного скрипта исправления, если этот параметр не соответствует требованиям.

sudo ./CMEnroll -s -ignorecertchainvalidation -u

Обратная связь

Были ли сведения на этой странице полезными?

Срок действия сертификата пакета Acrobat или Reader для Mac истек

Срок действия сертификата, который использовался для подписи установщиков и пакетов обновления Mac для Adobe Acrobat и Reader, истек 21 февраля 2017 года. Поскольку срок действия этого сертификата истек, система macOS стала помечать многие установщики и исправления Acrobat или Reader как неподписанные или просроченные.

Это затрагивает следующих установщиков полных версий и исправлений:

• Пакеты Acrobat Continuous до 15.016.20041
• Пакеты Acrobat Reader Continuous до 15.016.20039
• Пакеты Acrobat 2015 до 15.006.30173
• Пакеты Acrobat Reader 2015 до 15.006.30172
• Пакеты Acrobat и Reader XI до 11.0.17

Если вы попытаетесь установить любые из затронутых пакетов, появится следующее предупреждение:

При попытке задать эти пакеты с помощью командной строки, MAC OS заблокирует установку и появится сообщение об ошибке установки.

Решение: загрузите последнюю версию или исправление

Установщики полных версий

Данная проблема не проявляется в последних версиях установщиков полных версий. Если выдается предупреждение при использовании пакета установщика полной версии Acrobat/Reader, загрузите последнюю версию.

Пакеты установщика в этом местоположении были обновлены, и при установке из последних версий пакетов никаких проблем возникать не должно.

Исправления

В последних пакетах исправлений для всех замеченных ошибок подобная проблема не возникает. Компания Adobe рекомендует установить последние обновления:

• 15.023.20056 для Acrobat и Reader Continuous
• 15.006.30280 для Acrobat и Reader 2015
• 11.0.19 для исправлений для Acrobat и Reader XI

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

Однако подпись пакета действительна, и операционная система не блокирует установку. Это можно проверить с помощью команды pkgutil:

Пример вывода терминала для пакета 11.0.19 Acrobat приведен ниже. В нем указано, что пакет подписан сертификатом, который является доверенным в операционной системе:

Изменение параметров доверия для сертификата в Связке ключей на Mac

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

1. В приложении «Связка ключей» на Mac выберите связку ключей в одном из списков связок ключей, затем дважды нажмите сертификат.
2. Нажмите стрелку рядом с разделом «Доверие», чтобы увидеть условия доверия сертификата.
3. Чтобы отменить текущие условия доверия, выберите новые настройки доверия во всплывающих меню.

См. такжеИзменение условий доверия сертификатов на Mac

Не могу открыть приложения на macOS. Почему подпись кода OCSP оказалась миной замедленного действия

Две недели назад пользователи macOS начали сообщать о странных зависаниях при открытии приложений, не загруженных из Mac App Store. Многие подозревали аппаратные проблемы со своими устройствами, но из социальных сетей они узнали, что это широко распространённая проблема. И не случайно она возникла вскоре после запуска macOS Big Sur.

В конце концов, твит Джеффа Джонсона точно указал основную причину. Оказалось, что эппловская служба “OCSP Responder” слишком перегружена, поэтому macOS не могла проверить криптографические сертификаты разработчиков приложений.

Но почему служба OCSP Responder оказалась на критическом пути запуска приложений? В этой статье мы кратко обсудим подпись кода, как работает онлайн-протокол статуса сертификата (OCSP), почему он абсолютно неправильный и некоторые лучшие альтернативы. В отличие от других заметок о данном инциденте, я хочу обсудить именно практические криптографические аспекты (на высоком уровне) и предложить сбалансированную перспективу.

Подпись кода

На портале разработчиков Apple объясняет цель подписи кода:

Подпись кода вашего приложения гарантирует пользователям, что оно взято из известного источника и не изменено с момента последней подписи. Прежде чем интегрировать службы (app services), установиться на устройство или попасть в каталог приложений, приложение должно быть подписано сертификатом, выданным Apple.

Другими словами, чтобы приложению доверяли в macOS, его нужно подписать собственным сертификатом на основе пары ключей. Связка ключей используется для создания уникального сертификата «идентификатор разработчика», который включает в себя закрытый ключ для использования разработчиком и открытый ключ для распространения. Когда Apple подписала сертификат Developer ID, разработчик может использовать закрытый ключ для создания криптографических подписей на своих приложениях при каждом релизе.

При запуске приложения его подпись проверяется по открытому ключу сертификата разработчика. Затем проверяется сам сертификат, что срок его действия не истёк (сертификаты обычно действительны в течение одного года), и что в конечном итоге он подписан корневым сертификатом Apple. Также могут быть промежуточные сертификаты как часть цепочки вплоть до корневого сертификата. Это «цепочка доверия», поскольку сертификат Developer ID подписал приложение, промежуточный сертификат подписал сертификат Developer ID, а корневой сертификат Apple подписал промежуточный сертификат. Любое устройство Apple может проверить эту цепочку доверия и, следовательно, одобрить запуск приложения.

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

Если верификация не прошла, то пользователь увидит страшное окно:

Отзыв

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

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

В интернете это делается самым простым способом. Центр сертификации выдаёт вам список отозванных сертификатов (Certificate Revocation List, CRL) с серийными номерами всех отозванных сертификатов, и вы проверяете, что сертификат отсутствует в этом списке. Однако браузеры перестали использовать такой подход, так как список становился всё длиннее и длиннее. Особенно после того, как ужасающие эксплоиты вроде Heartbleed потребовали массового отзыва сертификатов.

Online Certificate Status Protocol (OCSP) — это альтернатива, позволяющая проверять сертификаты в режиме реального времени. Каждый сертификат содержит встроенный «ответчик OCSP» (OCSP Responder) — это URL-адрес, который вы запрашиваете, а он сообщает, был ли сертификат отозван. В случае с Apple это ocsp.apple.com . Так что теперь, в дополнение к проверке криптографической достоверности подписи, каждый раз при запуске приложения вы выполняете проверку в реальном времени на сайте Apple (с некоторым кэшированием), что они всё ещё считают сертификат разработчика легитимным.

Проблема доступности OCSP

Огромная проблема OCSP в том, что внешняя служба становится единой точкой отказа. Что произойдёт, если ответчик OCSP не работает или недоступен? Мы просто отказываемся проверять сертификат (hard-fail)? Или мы делаем вид, что проверка прошла успешно (soft-fail)?

Apple вынуждена использовать поведение soft-fail, иначе приложения не будут работать в офлайне. Все основные браузеры также реализуют поведение soft-fail, поскольку ответчики OCSP традиционно ненадёжны, а браузер хочет загрузить сайт, даже если ответчик центра сертификации временно не работает.

Но soft-fail (мягкий отказ) — не очень хороший вариант, потому что при наличии контроля над сетью злоумышленник может блокировать запросы к ответчику, и проверка будет пропущена. На самом деле такое «исправление» ошибки широко разошлось в твиттере во время этого инцидента: трафик к ocsp.apple.com блокировался строчкой в файл /etc/hosts. Многие оставят эту строчку в ближайшее время, поскольку отключение OCSP не вызывает никаких заметных проблем.

Инцидент

Если проверка OCSP у Apple построена на мягком отказе, то почему приложения зависали при отключении ответчика OCSP? Вероятно, потому что на самом деле это был другой сбой: ответчик OCSP на самом деле не был полностью отключён. Он просто плохо работал.

Из-за нагрузки от миллионов пользователей со всего мира, которые обновлялись на macOS Big Sur, серверы Apple замедлились и не отвечали должным образом на запросы OCSP. Но при этом работали достаточно хорошо, чтобы не сработал soft-fail.

Проблема приватности OCSP

В дополнение к проблеме доступности OCSP, протокол изначально не рассчитан на защиту приватности. Базовый запрос OCSP включает в себя незашифрованный HTTP-запрос к ответчику OCSP с серийным номером сертификата. Таким образом, не только ответчик может определить, какой сертификат вас интересует, но и ваш провайдер и любой другой человек, перехватывающий пакеты. Apple может составить список по порядку, приложения каких разработчиков вы открываете, и то же самое могут сделать посторонние лица.

Можно было бы добавить шифрование, и есть лучшая, более приватная версия под названием OCSP stapling, но Apple не сделала ни того, ни другого. На самом деле OCSP stapling не имеет смысла в этом сценарии, но эта технология иллюстрирует, что OCSP не должна допускать утечки данных по умолчанию.

Лучшее будущее

Этот инцидент вызвал оживлённую дискуссию в сообществе, причём одна сторона заявила: «Ваш компьютер на самом деле не ваш», а другая утверждает, что «Установить доверие к приложениям трудно, но Apple делает это хорошо». Я пытаюсь показать, что OCSP — это в любом случае ужасный способ управления отзывами сертификатов, а в будущем он приведёт к новым инцидентам, связанным с доступностью ответчиков и приватностью. На мой взгляд, это плохое инженерное решение — устанавливать зависимость запуска приложений от OCSP. По крайней мере, в краткосрочной перспективе они уменьшили ущерб, увеличив время кэширования ответов.

К счастью, практически созрел лучший метод отзыва сертификатов — CRLite. Он позволяет сократить до разумного размера списки всех отозванных сертификатов. В блоге Скотта Хельме даётся хорошее резюме, как CRLite использует фильтры Блума, чтобы вернуть прежний подход со списком отозванных сертификатов, который действовал до OCSP.

Устройства macOS могут периодически получать обновления этого списка CRL и выполнять проверку локально на устройстве, что решает проблемы доступности и конфиденциальности OCSP. С другой стороны, поскольку список отозванных сертификатов Developer ID намного меньше, чем список всех отозванных сертификатов PKI, стоит спросить, почему Apple не использует CRL. Возможно, они не хотят раскрывать информацию о том, какие сертификаты отозваны.

Заключение

В целом, этот инцидент стал хорошим поводом поразмышлять о модели доверия, которую продвигают такие организации, как Apple и Microsoft. Вредоносное ПО стало более изощренным, и большинство людей не в состоянии определить, безопасно ли запускать определённые бинарные файлы. Подпись кода кажется отличным криптографическим способом установить доверие для приложений и хотя бы связать приложения с известными разработчиками. И отзыв сертификатов является необходимой частью этого доверия.

Но всего несколько сбоев в процессе проверки OCSP портит всю криптографическую элегантность процесса подписи и проверки кода. OCSP также широко используется для сертификатов TLS в интернете, но там сбои менее катастрофичны из-за большого количества центров сертификации и повсеместного игнорирования сбоев со стороны браузеров. Более того, люди привыкли видеть веб-сайты время от времени недоступными, но они не ожидают того же от приложений на собственных компьютерах. Пользователей macOS обеспокоило то, что их собственные приложения пострадали из-за проблем инфраструктуры Apple. Однако это неизбежный результат, вытекающий из того факта, что проверка сертификатов зависит от внешней инфраструктуры, а никакая инфраструктура не является надёжной на 100%.

Скотт Хельме также выражает опасения по поводу власти, которую получают центры сертификации, если аннулирование сертификатов работает действительно эффективно. Даже если вас не беспокоит потенциальная возможность цензуры, иногда будут возникать ошибки, и их следует взвешивать относительно преимуществ безопасности. Как обнаружил один разработчик, когда Apple по ошибке отозвала его сертификат, риск работы на изолированной платформе заключается в том, что вас самого могут изолировать от неё.

• macOS
• Big Sur
• OCSP Responder
• подпись кода
• Online Certificate Status Protocol
• отзыв сертификатов
• CRLite

• Криптография
• Разработка под macOS
• Софт