СпонсорствоВойтиОтправить
Блог

macOS 27.2.1 лишает curl доверия к eMudhra. Что я бы проверил в приложении для Mac

Автор: Justinas Rolando, создатель MacPip

Короткий ответ

9 ноября 2026 г.: Apple выпустила macOS 27.2.1, а также 26.7.3 и 15.8.3 для более старых Mac. Помимо восьми исправлений безопасности, они закрывают пробел, оставшийся после компрометации сертификатов eMudhra: с 19 октября Safari, Mail и приложения на сетевых фреймворках и фреймворках безопасности Apple уже отказывались принимать плохие сертификаты (их число: 12), но инструменты командной строки вроде curl, git, python3 и openssl читали /etc/ssl/cert.pem и продолжали их принимать. Обновления убирают из этого файла пять корневых сертификатов, включая AAA Certificate Services. Если ваше приложение, установщик или скрипт обновления используют эти инструменты или поставляют собственный список доверенных корневых сертификатов, проверьте свои загрузки и собственные серверы на новых версиях.

Большинство обновлений Mac я устанавливаю и забываю. А вот macOS 27.2.1, вышедшую 9 ноября, я бы прочитал внимательно, если бы делал приложение для Mac: она меняет, каким сертификатам доверяют некоторые инструменты на каждом Mac. Apple выпустила её вместе с macOS Tahoe 26.7.3 и Sequoia 15.8.3 для более старых Mac, и во всех трёх одно и то же изменение.

Вот что произошло, кого это касается и что я бы проверил.

Что произошло

Те же обновления исправляют ещё восемь ошибок безопасности в Messages, AirPlay и Bluetooth, по данным MacRumors. Apple не сообщала, что какие-либо из них использовались в атаках.

Почему автору приложения для Mac это важно

Если ваше приложение обычное приложение на Swift и выходит в интернет через URLSession, то, скорее всего, оно было защищено ещё в октябре. На странице Apple речь о приложениях, использующих её сетевые фреймворки и фреймворки безопасности, а Howard Oakley, которого цитирует Michael Tsai, говорит, что приложения на стандартных API Apple используют хранилище доверия macOS.

Не защищены оказались приложения того типа, который выпускают многие независимые создатели:

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

Есть и вторая сторона. AAA Certificate Services это старый корневой сертификат Sectigo, которым подписано немало обычных сертификатов. Apple предупреждает, что инструменты, использующие только /etc/ssl/cert.pem, могут не проверить некоторые сайты, чьи цепочки проходят через удалённые корневые сертификаты. Если ваш сервер загрузок, лента обновлений или API лицензий оказались среди них, curl на обновлённом Mac может начать их отвергать.

Что бы я проверил на этой неделе

Это мои собственные шаги, а не шаги Apple.

  1. Обновите один Mac до 27.2.1 и проверьте загрузки из командной строки. Запустите свой установочный скрипт, brew install, если у вас есть cask, и curl -I для адресов загрузки, appcast и лицензий. Отказ принять сертификат проявится как ошибка, а не как медленная страница.
  2. Посмотрите на цепочку сертификатов своего сайта. Запустите openssl s_client -connect yourapp.com:443 -showcerts и прочитайте строки issuer. Если вы видите eMudhra, emSign или AAA Certificate Services, попросите хостинг или продавца сертификатов выдать цепочку, которая заканчивается другим корневым сертификатом.
  3. Выясните, каким хранилищем доверия на самом деле пользуется ваше приложение. Electron, Go, Rust со встроенными корневыми сертификатами, Python с certifi и Java приносят свои собственные. Обновите среду выполнения или пакет с корневыми сертификатами до версии, в которой плохие сертификаты убраны, и укажите это в заметках к релизу.
  4. Подготовьте ответ для поддержки. Если кто-то на старом Mac не может установить обновления, на странице Apple есть шаги для ручного удаления корневых сертификатов. Я бы дал ссылку на страницу Apple, а не вставлял в письмо команды с sudo.
  5. Попросите пользователей обновиться. Если ваши пользователи в основном технически подкованные, короткая заметка в следующем релизе или рассылке ничего не стоит.
  6. Проверьте файл на тестовом Mac. На странице Apple есть команда ниже, которая ничего не выводит, когда два главных корневых сертификата удалены.
openssl crl2pkcs7 -nocrl -certfile /etc/ssl/cert.pem | openssl pkcs7 -print_certs -noout | grep -E 'emSign ECC Root CA - G3|AAA Certificate Services'

Чего бы я не делал

Я бы не стал отключать проверку сертификатов в скрипте, чтобы ошибка исчезла. Именно от этого и защищает всё это изменение. И я бы не говорил пользователям, что их Mac взломан. Нет признаков того, что ключи использовались, а большинство приложений были защищены ещё в октябре.

Взгляд MacPip

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

Новое сегодня: проверка манифеста конфиденциальности. Вставьте свой PrivacyInfo.xcprivacy, и она сверит каждый тип данных, цель и код обязательной причины, например CA92.1, со списками самой Apple. Она также говорит, что Apple требует на Mac, а что нет. Всё работает на странице, ничего не отправляется. Рядом лежат разбор Info.plist и разбор нотаризации. А если вашего приложения для Mac ещё нет на MacPip, добавить его можно бесплатно.

Источники

Читайте дальше

Отправьте приложениеБесплатные инструменты для создателей