Списки доступных доверенных корневых сертификатов в ОС iOS – Служба поддержки Apple (RU)

Знакомьтесь, Боб — матёрый ios разработчик, Алиса — не менее матёрая тестировщица. Дело было вечером дело было в пятницу. Боб дофиксил багу, вроде бы протестил на своих девайсах. Затем Боб запускает уже отточенные до автоматизма команды:

git checkout develop
git merge bug_fix_#999
git checkout master && git merge develop --no-ff ....
git push ....

На пуш на сервере срабатывает jenkins/teamcity/travis, который запускает билд. В это же самое время наш Боб пишет Алисе, что скоро пойдет домой, и хочет, чтобы аппа ушла сегодня в app store на апрув, дабы выиграть лишние пару дней, так как на носу выходные, если, конечно, приложение пройдет ручное тестирование Алисы.

Приложение Боба довольно обычное: пару сотен компилируемых класс файлов, еще с десяток cocoapods зависимостей ну и кучка сторибордов — Боб ценит своё время и время коллег поэтому не пишет UI в коде. Боб знает, что его приложение с чистого старта на сервере собирается за 4 минуты для develop версии, которое идет на тест Алисе, и столько же или чуть больше для production версии. Боб также знает, что ему нужно около 10 минут, чтобы дождаться окончания полной сборки и затем сообщить Алисе, что она может приступать к тестированию. Боб человек ответственный, поэтому по истечении 10 минут после пуша проверяет статус билда, так как знает, что сервер — это отдельный параллельный мир со своими правилами, законами и странностями.

Пятница, вечер, Боба отделяет от долгожданных выходных только 10 минут, после которых передаст эстафету Алисе. Боб вбивает в сафари bobcompany.ci/dashboard, где видит красную лампочку напротив своего приложения, глаза Боба потускнели, разочарованию не было предела. Боб жмет на show more, где его встречает ошибка:

Code Sign error: No codesigning identities found: No codesigning identities (i.e. certificate and private key pairs) that match the provisioning profile specified in your build settings (“com.company.bob”) were found.

Тут нервы Боба совсем сдают:

*Кратко об ошибке, она проявляется, когда мы пытаемся подписать приложение несуществующим сертификатом, под несуществующим понимается или он не установлен на машине, или он устарел и mobileprovision заведен на более свежую версию сертификата того же аккаунта для того же бандла.

И самое обидное, что эта ошибка только для production версии билда, который запускается вторым после develop версии, причем, сначала xcode компилирует зависимости (cocoapods) и уже только после проверяет валидность подписи, то есть только когда собирает основное приложение. Поэтому ошибка проявляется примерно во второй половине процесса сборки, из-за чего первые 6-7 минут потрачены в пустую, от чего Боб расстроен еще больше.

Наш разработчик Боб не первый раз сталкивается с этой проблемой, ведь он работает в большой компании, где несколько команд ios разработчиков, где нормальная практика для разработки использовать один Apple аккаунт на несколько человек. Да, Боб знает про Xcode плагин https://github.com/neonichu/FixCode, но ведь не заставлять же его насильно всем ставить, разработчики нежные создания, не все любят, когда их заставляют что-то делать против их воли, Боб сам такой.

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

Ну окей. Первым делом Боб проверяет какие сертификаты, вообще, есть на машине:

security find-identity -v login.keychain

Что выдает

  1) 40948A3CA3527F580B9ECB2131DE6B1938FB3D7C "iPhone Developer: Mike ... (KSDA3C3QF2)"
  2) 0279CB81AEAD8CE015282DD1FA76CE520A815C4D "iPhone Developer: Bob .. (4WT74HLM2M)"
  3) 79A2544B1A63C3F9D3DA3FFAB199FEAADB7EC306 "iPhone Developer: Alica ... (VJ53F2J4EK)"
  ....
     24 valid identities found

Так, как минимум, в keychain, который используется по дэфолту на сервере, есть 24 сертификата. Боб знает, что каждый mobileprovision файл создается на какой-то один конкретный сертификат. Нужно выяснить на какой сертификат создан mobileprovision файл для которого упал билд и понять, что же произошло с сертификатом. Нужно, вообще, понять как mobileprovision файл связан с сертификатом. Боб знает, что develop версия приложения собралась, поэтому на сервере точно есть этот сертификат и сейчас нужно понять как он соотносится с mobileprovision файлом. Для этого Бобу нужно найти mobileprovision файл и данные о сертификате, чтобы начать искать какие-то соответствия между ними.

Ищем mobileprovision файл по его бандлу (если ваш бандл wildcard, то можно искать по любым другим признакам):

cd ~/Library/MobileDevice/Provisioning Profiles
find . -name "*.mobileprovision" -type f -exec grep -H -n -a {} -e "com.company.bob" ;

Отлично, мы нашли наш файл:

./f98a06f3-21c2-4de0-975f-5df74197c731.mobileprovision:30:		<string>4HUHB9J47M.com.company.bob</string>

В файле есть префикс 4HUHB9J47M у бандла. Из ранее полученного списка сертификатов ничто с этим значением не совпадает. Поэтому Бобу приходится идти в developer.apple.com и искать на какой же аккаунт создан этот mobileprovision файл. Методом тыка он выясняет, что это сертификат Майка:

2) 40948A3CA3527F580B9ECB2131DE6B1938FB3D7C "iPhone Developer: Mike .. (KSDA3C3QF2)"

Отлично, теперь у нас есть с чем работать. Боб у нас не криптоаналитик или секурити ресерчер, но он хороший гуглер, поэтому он с легкостью нашел способ как получить необходимую информацию из сертификата.

Вытаскиваем данные в .pem файл:

security find-certificate -p -c "iPhone Developer: Mike .. (KSDA3C3QF2)" > cert.pem

В файле получаем следующее:

-----BEGIN CERTIFICATE-----
MIIFnjCCBIagAwIBAgIIN8GwnYhLQ/kwDQYJKoZIhvcNAQELBQAwgZYxCzAJBgNV
BAYTAlVTMRMwEQYDVQQKDApBcHBsZSBJbmMuMSwwKgYDVQQLDCNBcHBsZSBXb3Js
ZHdpZGUgRGV2ZWxvcGVyIFJlbGF0aW9uczFEMEIGA1UEAww7QXBwbGUgV29ybGR3
aWRlIERldmVsb3BlciBSZWxhdGlvbnMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
...
....
.....
lD ocFo6 mab/Ph6mTJOZkZu hnqhzbTD9Q9dXKWkeXAwTqaESNfnhnuOdfCX3vu
YAz0Hb46G9fkLa5lHjVydbtms685C uz9Ss4GNRfji1cz5KyblAQAAsqQBUiCwnb
z34=
-----END CERTIFICATE-----

Как оказалось, с этого файла можно считать информацию о сертификате, попробуем получить наиболее интересную для нас:

openssl x509 -noout -fingerprint -in cert.pem

Выдает нам:

SHA1 Fingerprint=40:94:8A:3C:A3:52:7F:58:0B:9E:CB:21:31:DE:6B:19:38:FB:3D:7C

Если убрать двоеточия, то получим 40948A3CA3527F580B9ECB2131DE6B1938FB3D7C, это как раз sha1 сертификата Майка, который мы можем увидеть в UI в Keychain:

Мы также можем получить срок действия сертификата, если нужно написать валидатор истёкших сертификатов:

openssl x509 -noout -startdate -in cert.pem // Feb 27 07:13:41 2021 GMT
openssl x509 -noout -enddate -in cert.pem // Feb 26 07:13:41 2021 GMT

Это же мы видим и в keychain:

В общем с сертификатом всё ясно. «Как же его привязать к нашему mobileprovision файлу?» — думает любопытный Боб. Давайте сначала посмотрим на mobileprovision файл поближе:

security cms -D -i f98a06f3-21c2-4de0-975f-5df74197c731.mobileprovision 

Вывод нам дает интересную информацию для поля data, а именно:

<data>
MIIFnjCCBIagAwIBAgIIN8GwnYhLQ/kwDQYJKoZIhvcNAQELBQAwgZYxCzAJBgNV
BAYTAlVTMRMwEQYDVQQKDApBcHBsZSBJbmMuMSwwKgYDVQQLDCNBcHBsZSBXb3Js
ZHdpZGUgRGV2ZWxvcGVyIFJlbGF0aW9uczFEMEIGA1
...
...
YAz0Hb46G9fkLa5lHjVydbtms685C uz9Ss4GNRfji1cz5KyblAQAAsqQBUiCwnb
z34=
</data>

Где-то это Боб уже видел, похоже на содержание ранее полученного .pem файла:

-----BEGIN CERTIFICATE-----
MIIFnjCCBIagAwIBAgIIN8GwnYhLQ/kwDQYJKoZIhvcNAQELBQAwgZYxCzAJBgNV
BAYTAlVTMRMwEQYDVQQKDApBcHBsZSBJbmMuMSwwKgYDVQQLDCNBcHBsZSBXb3Js
ZHdpZGUgRGV2ZWxvcGVyIFJlbGF0aW9uczFEMEIGA1UEAww7QXBwbGUgV29ybGR3
aWRlIERldmVsb3BlciBSZWxhdGlvbnMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
...
....
.....
lD ocFo6 mab/Ph6mTJOZkZu hnqhzbTD9Q9dXKWkeXAwTqaESNfnhnuOdfCX3vu
YAz0Hb46G9fkLa5lHjVydbtms685C uz9Ss4GNRfji1cz5KyblAQAAsqQBUiCwnb
z34=
-----END CERTIFICATE-----

Тут Боб понял, вот она зацепка mobileprovision файла на сертификат.

Итого, нам нужно взять наш mobileprovision файл, вытащить из него значение для поля data, затем пробежать по всем валидным сертификатам и сравнить с данными из их .pem представления. Боб тут же накидал небольшой скрипт, который передал коллегам из бэкенда, чтобы они его запускали перед каждой сборкой ios проектов. Скрипт запускается достаточно просто:

ruby cert_checker.rb f98a06f3-21c2-4de0-975f-5df74197c731.mobileprovision

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