Комментарии 10
Было бы круто, если бы начиная с Профили предоставления (Provisioning profiles) были бы какие-то картинки, схемы или скриншоты с порталов Apple, для большего понимания.
Поддерживаю.
Не хватает конкретики и иллюстраций для лучшего восприятия.
Сертификаты, ключи, провиженинги и их виды. Разъяснений не хватает.
От себя добавлю (свою статью на эту тему не оформил, но могу сделать это очень быстро) - интересующимся следует посмотреть в сторону fastlane match и как это работает.
Fastlane- это ruby-фрэймворк который позволяет удобно собирать приложения благодаря написанным actions (функциям) и match является одной из них - позволяет хранить секреты в зашифрованном виде в приватном репозитории/хранилище .
Абсолютно правы. Моя недоработка. Буду добавлять больше наглядного материала. Спасибо
Непонятно почему статья называется Сертификаты Apple, если рассказано про обычные сертификаты, которые используются в любой системе.
Не нашел НИ ОДНОГО нюанса, относящегося именно к Apple
Самое интересное здесь то, что таковые центры сертификации не скачиваются, они уже зашиты в программное обеспечение. - а как же недавний инцидент с отзывом сертификатов у известных нам все и то, что теперь новые сертификаты можно самому скачать и установить? И также в вебмани также существовала процедура скачивания и установки сертификата которого изначально не бывает на компьютере?
и еще - вы описали систему из двух ключей - но вроде если их будет 4 то обмен между сервером и клиентом станет полностью безопасен и без дополнительных центров и сертификатов изначально находящихся на ПК?
Подскажите, пожалуйста, если абстрактные Алиса и Боб обменяются публичными ключами - "вор" все еще сможет что-то прочесть (без доступа к приватным ключам)? Т е Алиса шифрует свои сообщения публичным ключом Боба, а Боб - публичным ключом Алисы.
И да, ничего специфичного для iOS.
Мне кажется абсолютно некорректно описана криптография как таковая.
Один ключ служит для того, чтобы зашифровать сообщение, второй же, чтобы расшифровать его
Строго говоря шифровать и подписывать можно как закрытым так и открытым ключом. Правда шифровать закрытым бесполезно.
вор всё еще может перехватить ваш открытый ключ.
Смысл открытого ключа именно в том что он ОТКРЫТЫЙ. От того что его перехватят ничего не произойдет.
После чего, сервер отправляет вам зашифрованное сообщение, которое вы, в свою очередь, расшифровываете с помощью открытого ключа.
Нет, сервер шифрует сообщение клиентским открытым ключом. В такой схеме нужно 2 открытых и 2 закрытых ключа внезапно. Другая схема - клиент шифрует сеансовый ключ открытым сервера и отправляет серверу, далее уже идет обмен с использованием сеансового.
Центры сертификации предоставляет вам файл, содержащий публичный ключ, который зашифрован приватным ключом центра сертификации. Результатом всей это операции и являются сертификаты.
Полет фантазии вообще не понял. В хранилище браузера содержится корневой сертификат центра (публичный ключ), сайт предоставляет подписанную цепочку сертификатов от корневого, клиент проверяет доверяет ли он цепочке. С таким же успехом корневой может быть добавлен вручную или политикой домена или проверка может основываться вообще не на коренных а на минимальном количестве "доверенных" сертификатов подписи которых должны стоять (например я доверяю Пете, Маше, Кате, если двое из них доверяют Васе - я доверяю ему тоже).
Сертификаты Apple. Понимание. Что это и зачем вообще нужны?