Как обновить подпись мобильного клиента 1С

Подпись мобильного клиента 1С — это цифровой ключ, которым подписывается собранное приложение (APK для Android или пакет для iOS) перед установкой на устройство. Операционная система проверяет подпись при установке и обновлении: если подпись новой версии не совпадает с подписью уже установленного приложения, обновление будет отклонено. Поэтому к обновлению подписи нужно подходить аккуратно и понимать последствия.

Чаще всего обновить подпись требуется в трёх ситуациях: истёк срок действия сертификата ключа, ключ скомпрометирован или утерян, либо приложение переводится на нового разработчика или новую учётную запись поставщика. Во всех случаях порядок действий похож: создаётся новый ключ, его параметры указываются в настройках мобильного приложения в конфигураторе 1С, выполняется пересборка, а затем новая версия распространяется на устройства пользователей.

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

Что такое подпись мобильного приложения и когда её нужно менять

В экосистеме 1С мобильный клиент собирается из конфигурации с помощью сборщика мобильных приложений. На этапе сборки исполняемый пакет подписывается ключом разработчика — файлом хранилища ключей (keystore для Android) или сертификатом с профилем обеспечения (для iOS). Подпись удостоверяет, что приложение выпущено именно вами, и защищает его от подмены.

Основные признаки того, что подпись пора обновить: сборщик выдаёт ошибку об истёкшем или недействительном сертификате, устройство отказывается устанавливать обновление с сообщением о конфликте подписей, либо вы планово меняете инфраструктуру выпуска приложений. Также подпись придётся сменить, если файл ключа утерян без резервной копии — восстановить его невозможно.

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

Подготовка: что сделать до смены подписи

Первый шаг — зафиксировать текущее состояние. Сохраните резервную копию старого хранилища ключей и запишите его параметры: псевдоним ключа (alias), пароли, срок действия. Эти данные понадобятся, если потребуется откатиться или параллельно поддерживать старую сборку. Пароли храните в защищённом хранилище, а не в открытом виде рядом с проектом.

Второй шаг — обеспечить сохранность данных пользователей. Если мобильный клиент работает в автономном режиме с синхронизацией через веб-сервисы или обмен данными, инициируйте полную синхронизацию на всех устройствах до начала работ. Предупредите пользователей о дате перехода, чтобы они не вводили критичные данные в «пограничный» период.

Третий шаг — проверить инструментарий. Для сборки вам понадобятся: установленная Java JDK с утилитой keytool, Android SDK, сборщик мобильных приложений 1С и конфигуратор с доступом к конфигурации мобильного приложения. Убедитесь, что версии компонентов совместимы между собой — несовместимость частая причина сбоев сборки.

Создание нового ключа подписи

Новое хранилище ключей для Android создаётся командой keytool. Укажите алгоритм RSA, достаточный срок действия и осмысленный псевдоним ключа. Пример команды приведён ниже — подставьте свои пути и имена.

Указание новой подписи в конфигурации 1С

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

Обратите внимание на смежные параметры: имя пакета приложения (application ID) менять не нужно — оно должно остаться прежним, чтобы пользователи и инфраструктура воспринимали приложение как то же самое. Меняется только подпись, а не идентификатор. Версию приложения при этом стоит увеличить, чтобы отличать новую сборку от старой.

1. 1
   Синхронизируйте данные на всех мобильных устройствах с центральной базой
2. 2
   Создайте новое хранилище ключей командой keytool и сделайте резервную копию
3. 3
   Укажите параметры нового ключа в настройках мобильного приложения в конфигураторе
4. 4
   Увеличьте номер версии приложения, сохранив прежнее имя пакета
5. 5
   Пересоберите мобильный клиент через сборщик мобильных приложений
6. 6
   Установите новую сборку на тестовое устройство и проверьте работу
7. 7
   Удалите старое приложение на рабочих устройствах и установите новую сборку

Если пароли хранилища в конфигурации хранятся в открытом виде, ограничьте доступ к файлам конфигурации и к компьютеру сборки. Закрытый ключ и пароли — это компрометирующая информация: получивший их сможет выпускать приложения от вашего имени.

Пересборка и установка приложения на устройства

Запустите сборку мобильного приложения штатным способом — через сборщик мобильных приложений 1С. При корректно указанных параметрах нового ключа сборка пройдёт без ошибок подписи. Если сборщик сообщает о неверном пароле или отсутствии ключа, перепроверьте путь к файлу, псевдоним и пароли — это самые частые причины сбоя на этом этапе.

Полученный APK-файл сначала установите на тестовое устройство. Помните: если на нём стоит старая сборка с другой подписью, установка поверх завершится ошибкой (обычно с сообщением о конфликте сертификатов или INSTALL_FAILED_UPDATE_INCOMPATIBLE при установке через ADB). Это ожидаемое поведение, а не дефект сборки: удалите старое приложение и установите новое начисто.

После установки проверьте ключевые сценарии: запуск, подключение к центральной базе, синхронизацию, работу автономного режима, если он используется. Только после успешной проверки распространяйте сборку на рабочие устройства пользователей — через MDM-систему, файловый ресурс или прямую передачу APK, в зависимости от принятой схемы доставки.

Контрольные точки

Как проверить результат

Подпись собранного APK

Норма

Сертификат соответствует новому ключу, срок действия достаточный

Тревожный признак

Подпись осталась старой или сборка не подписана

Установка на устройство

Норма

После удаления старой версии приложение устанавливается и запускается

Тревожный признак

Ошибка конфликта подписей — старая версия не удалена

Синхронизация данных

Норма

Данные обмениваются с центральной базой без ошибок

Тревожный признак

Ошибки подключения или расхождение данных после обмена

Особенности для iOS и распространения через магазины

Для iOS ситуация отличается: подпись формируется сертификатом разработчика Apple и профилем обеспечения (provisioning profile). Обновление подписи здесь обычно означает перевыпуск сертификата в учётной записи разработчика Apple и обновление профиля, после чего новые параметры указываются при сборке. Поскольку распространение корпоративных iOS-приложений жёстко привязано к учётной записи, смена подписи вне той же учётной записи фактически означает выпуск нового приложения.

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

Варианты действий при проблемах с подписью

Продлить использование текущего ключа

Подходит, если ключ действует и доступен. Минимум рисков, обновление проходит поверх установленного приложения.

Сменить ключ с переустановкой

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

Сброс ключа через консоль магазина

Вариант для приложений, опубликованных в Google Play. Дольше по времени, зависит от подтверждения площадкой.

Типичные ошибки и как их избежать

Самая частая ошибка — попытка обновить приложение поверх версии с другой подписью. Пользователь получает отказ установки и не понимает причину. Избежать этого можно только организационно: заранее проинформируйте пользователей, что старую версию нужно удалить, и дайте понятную инструкцию.

Вторая типичная проблема — неверно указанный псевдоним или пароль ключа в настройках конфигурации, из-за чего сборка падает с ошибкой подписи. Проверяйте параметры командой keytool -list до начала сборки. Третья ошибка — потеря нового ключа сразу после перехода: если хранилище не скопировано в резерв, следующая смена подписи станет вынужденной.

Наконец, не забывайте обновить сопроводительную документацию: зафиксируйте дату смены подписи, параметры нового ключа (без паролей в открытом виде) и порядок установки. При следующей ротации это сэкономит значительное время.

Частые вопросы

Можно ли обновить подпись без переустановки приложения на устройствах?

Нет, для Android это технически невозможно: система сравнивает сертификаты старой и новой версии и отклоняет установку при несовпадении. Единственный путь — удалить старое приложение и установить сборку с новой подписью. Поэтому смену подписи планируют заранее и совмещают с выгрузкой данных.

Что делать, если файл ключа утерян?

Восстановить закрытый ключ невозможно. Создайте новое хранилище ключей, пересоберите приложение и организуйте чистую установку на устройствах с предварительной синхронизацией данных. Если приложение опубликовано в Google Play, используйте процедуру сброса ключа загрузки в консоли разработчика.

Как проверить, каким ключом подписана текущая сборка?

Используйте утилиту apksigner из Android SDK (команда apksigner verify --print-certs путь_к_apk) или keytool в связке с jarsigner. Сравните отпечаток сертификата с данными вашего хранилища ключей — это надёжный способ убедиться, что сборка подписана нужным ключом.

Нужно ли менять имя пакета при смене подписи?

Нет, имя пакета (application ID) менять не следует — иначе приложение станет полностью новым для системы, MDM и пользователей. Меняется только ключ подписи, идентификатор приложения остаётся прежним.

Какой срок действия задать новому ключу?

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

Отличается ли процедура для iOS-версии мобильного клиента?

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