Это перевод статьи, опубликованной на сайте https://travellingtechguy.blog/jamf-pro-and-its-certificates/

Всем привет

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

При работе с Jamf Pro вам повстречаются различные сертификаты. Разнообразие оных будет зависеть от того, какую инсталляцию Jamf Pro вы используете и какие интеграции у вас настроены.

Перед погружением в детали, я перечислю типы сертификатов. Далее, я опишу каждый тип отдельно. В зависимости от важности, некоторым сертификатам будет уделено больше внимания, чем остальным.

Итак:

• сертификат SSL для Tomcat
• центр сертификации Jamf Pro
• сертификаты для подписи
• сертификаты устройств
• сертификаты APNS
• сертификаты LDAPs, SCEP proxy, SCCM, GSX…

Сертификат SSL для Tomcat

Этот сертификат является самым простым для объяснения, но это не умаляет его значимость.

Предположу, что важность HTTPS и SSL понимают все. Но что же этот сертификат делает на самом деле? Все просто: он подтверждает личность сервера. При этом не имеет значения, выпущен ли этот сертификат для конкретного FQDN или же это Wildcard. По факту это означает то, что кто-то, кому доверяет весь мир, проверил идентичность этого сервера и выдал сертификат в качестве доказательства. В моем случае это DST Root CA, он же Let’s Encrypt:

Но если кто-либо пытается зайти на сервер Jamf Pro (или регистрирует свое устройство в Jamf Pro по ссылке) и увидит сообщение ниже – у него возникнет подозрение, что тут что-то не так.

В принципе, все очевидно. Но как насчет устройств, которые подключаются к Jamf Pro? Точно так же. Всякий раз, когда Mac или iOS-устройство контактируют с сервером Jamf Pro, они проверяют сертификат SSL. Точно так же, как и при любом возможном соединении HTTPS/SSL. Сертификат SSL недействителен? До свидания! Посмотрите, что происходит при выполнении команд sudo jamf policy или sudo jamf recon, если срок действия SSL-сертификата сервера Jamf Pro истек или он недействителен (например,при неверно указанном FQDN):

Я наблюдал ситуации, когда люди впадали в панику после того, как внезапно прерывалась связm с локальным сервером Jamf Pro. Чаще всего это связано именно с сертификатом SSL, нежели чем с проблемами самого Tomcat. Особенно, если был загружен новый сертификат.

ЗАМЕЧАНИЕ: несмотря на то, что такие проблемы могут быть связаны с самим сертификатом SSL, возможно, что загруженный сертификат SSL не имеет доступа к промежуточному центру сертификации или Tomcat не был перезагружен после загрузки нового сертификата.

А за пользователей облачного Jamf Cloud уже постарались волшебники из Jamf:

Исходя из этого, требуется ли покупать свой собственный сертификат SSL и загружать его в локальный Jamf Pro?

Несмотря на то, что это рекомендуемый способ, он не является обязательным. При установке нового сервера Jamf Pro автоматически создается встроенный центр сертификации (ЦС, см. ниже). Этот центр сертификации может быть использован для выдачи сертификата SSL для Tomcat.

ЗАМЕЧАНИЕ: при установке нового сервера Jamf Pro этот шаг (если не загружать публично доверенный SSL-сертификат) является обязательным! В процессе установки создается встроенный ЦС, но он автоматически не используется для выдачи сертификата Tomcat. Вместо этого создается временный самоподписанный сертификат, который НЕ подходит для связи с устройством, так как устройства не могут автоматически доверять этому сертификату. Перезагрузка Tomcat необходима после каждого изменения сертификата SSL.

А как доверять встроенному ЦС устройствам и пользователям, пытающимся коммуницировать с Jamf Pro или заходить в веб-интерфейс?

Для пользователей все просто: нужно доверять администратору Jamf или сотруднику ИТ, которые говорят, что подтверждать доверие сертификату SSL требуется вручную. Поскольку встроенный центр сертификации не является публично доверенным центром сертификации, каждый браузер будет (или должен) предупреждать пользователя о потенциальной проблеме с SSL. Поэтому придется вручную отменить предупреждение и принудительно подключиться к Jamf Pro GUI.

ЗАМЕЧАНИЕ: Если в Safari достаточно добавить сертификат в Keychain, то Google Chrome с некоторых пор прекратил давать возможность вручную заходить на сайты с невалидным сертификатом.

С устройствами по другому. Выше мы обсуждали, что если устройство не доверяет сертификату SSL, то подключение невозможно. При Enrollment сервер Jamf Pro устанавливает сертификат ЦС. Но как начать сам Enrollment? К счастью, в настройках Jamf Pro есть возможность игнорировать проверку SSL во время Enrollment.

Полезно знать следующее: какая бы проблема не случилась с вашим сертификатом SSL – это не так страшно, как кажется. Вы всегда можете загрузить новый сертификат или временно вернуться к сертификату, выпущенному встроенным ЦС. на процесс Enrollment это не повлияет.

Внутренний СЦ в Jamf Pro

Как обсуждалось выше, в процессе установки сервера Jamf Pro создается встроенный Jamf Pro Certificate Authority. Сертификат этого ЦС устанавливается на каждое устройство в процессе enroll.

Одна из функций этого ЦС была рассмотрена выше: выдача сертификата SSL (при условии, что не используется публичный сертификат) для Tomcat, чтобы обеспечить доверенную связь между Jamf Pro и устройствами/пользователями.

Но ЦС используется и для других целей, например для профилей MDM, которые используются для отправки команд на устройства macOS и iOS и для Apple MDM Framework (Apple Push). Соответственно этот профиль должен быть подписан доверенным ЦС.

По умолчанию профиль MDM подписывается ЦС, встроенным в Jamf Pro, или, если быть более точным, подписывается “подписывающим сертификатом”, выпущенным встроенным СЦ (смотрите ниже).

ЗАМЕЧАНИЕ: более крупные компании могут иметь политики безопасности, которые требуют того, чтобы все используемые сертификаты выдавались только внутренним ЦС. Поэтому Jamf Pro имеет возможность использовать профиль MDM, подписанный внешним ЦС. Смотрите скриншот ниже. Я не буду давать советов, а подмечу одну вещь: если вы все-таки решите подписывать MDM профили ‘внешним ЦС’, и с этим ЦС случится что-нибудь неустранимое (маловероятно, но все же), то нет никакой возможности переключиться на другой ЦС или вернуться обратно к профилям MDM, подписанным встроенным ЦС Jamf Pro без повторного enroll всех устройств!

Включение такой опции приведет к тому, что Jamf Pro начнет подписывать все профили MDM через “внешний ЦС”, и это НЕ имеет никакого отношения к сертификату SSL для Tomcat.

Сравните с MDM профилем, подписанным ЦС, встроенным в Jamf Pro:

Подписывающие сертификаты

Итак, мы рассмотрели встроенный Jamf Pro CA, и обсудили его основную цель: подписание “подписывающего сертификата”, который подписывает профили MDM.

Однако есть и другие “сертификаты подписи”, которые автоматически генерируются Jamf Pro:

Как вы можете видеть, есть “сертификат подписи” для macOS и другой — для iOS; а также различные “сертификаты подписи” для других частей функционала Jamf Pro, таких как: DEP, Education Support, JSON, Config Profiles и т.д…..

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

ЗАМЕЧАНИЕ: FileVault2Comm ‘signing cert’ используется для функциональности escrow ключа восстановления FileVault, но давайте держаться подальше от FileVault в этом посте, иначе мы никогда не закончим статью.

Сертификаты устройств

Чтобы обеспечить связь между устройствами и Jamf Pro, первые должны предоставить свою идентификационную информацию. Также, как и Jamf Pro в случае с сертификатом Tomcat SSL.

Для этого каждому устройству выдается “Сертификат идентификации устройства” (Device Identity Certificate), который встроен в профиль MDM:

В iOS этот сертификат отображается в профиле MDM:

В macOS вы увидите этот сертификат в профиле MDM и в System Keychain:

В Jamf Pro вы найдете эти сертификаты, когда нажмете на цифры рядом со встроенным ЦС в настройках сертификатов PKI:

При необходимости эти сертификаты могут быть отозваны:

ЗАМЕЧАНИЕ: отзыв этих сертификатов в Jamf Pro, или удаление/повреждение их на устройствах СЛОМАЕТ ВСЕ СВЯЗИ сервера MDM с устройством!

Как было указано выше, эти сертификаты (Device Identity Certificates) используются только для взаимодействия с MDM. Однако, в macOS есть и агент Jamf Pro, “Jamf Binary”, который является частью Jamf Pro и дополняет функционал MDM (Policies, Patch Management, Inventory updates, и т. д.). Для этого дополнительного функционала компьютеры macOS также должны подтвердить свою “личность” в Jamf Pro. Следовательно, компьютеру выдается еще один сертификат, “удостоверяющий личность”: “сертификат устройства” (device certificate).

Этот сертификат можно найти в Jamf.keychain (не в System/Login Keychain, а в отдельной Keychain):

/Library/Application Support/JAMF/JAMF.keychain

Подобно “Сертификату идентификации устройства” (Device Identity Certificate), “сертификат устройства” (device certificate) можно найти в настройках PKI в Jamf Pro. Отзыв, удаление или повреждение этого сертификата на устройстве приведет к тому, что связь c Jamf БУДЕТ ПОРВАНА (при условии, что в Jamf Pro Settings > Security > Enable certificate-based authentication включена аутентификация на основе сертификата):

ВАЖНОЕ ЗАМЕЧАНИЕ: и “сертификат устройства“ (device certificates), и “сертификат идентификации устройства“ (Device Identity Certificate) действительны в течение 5 лет после регистрации устройства на сервере Jamf. Возможно, вы уже сталкивались с обсуждениями, связанными с тем, что эти сертификаты иногда не обновляются автоматически. Это радует!

Начиная с версии 10.23, Jamf Pro позволяет обновлять “сертификаты идентификации устройств” (и профиль MDM тоже) с помощью (массовых) Remote commands. Кроме того, “сертификаты устройств”, используемые для Jamf Management Framework / Binary также будут автоматически обновлены.

Cертификат APNS

Jamf Pro требует действительного сертификата push для соединения со службой Apple Push Notification Service (APNS). Это необходимо для выполнения следующих действий:

• Отправлять профили конфигурации для macOS, а также, отправлять remote commands на компьютеры macOS
• Устанавливать приложения из Mac App Store
• Enroll и управление устройствами iOS

Хотя этот сертификат можно считать самым важным для MDM, я не буду вдаваться в подробности, так как тема изучена уже вдоль и поперек. Лучше я приложу ссылки на документацию:

• https://docs.jamf.com/jamf-pro/administrator-guide/Push_Certificates.html
• https://support.apple.com/en-euro/guide/server/apde0e927ee/5.9/mac/10.15

Однако, есть и еще один ‘push certificate’, который можно настроить в Jamf Pro: Push Proxy certificate.

Jamf Push Proxy обеспечивает связь между сервером Jamf Pro и устройствами, на которых установлено приложение Jamf Self Service. По этому каналу связи обеспечивается отправка уведомлений в приложение Self Service. Сам сертификат обновляется автоматически.

• https://docs.jamf.com/10.21.0/jamf-pro/administrator-guide/Jamf_Push_Proxy.html

Сертификаты для интеграций с LDAPs, SCEP Proxy, SCCM, GSX…

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