Перейти к содержанию

HOWTO: License signing key — generation, deployment, rotation#

Эта инструкция описывает операционную процедуру для production-инсталляций Ruxeo: как сгенерировать продакшн-ключевую пару для подписи лицензионных ключей, как развернуть public key на инсталляции заказчика, и как ротировать ключ при компрометации или периодическом обновлении.

См. также DOCS/MECHANISMS/RU/LICENSING.md §2.1 (crypto-service), §5.1 (configuration), §6.1 (был placeholder, iter5 → Resolved).

1. Архитектура#

1.1 Назначение#

Лицензионный ключ (RXLC-...) содержит RSA-2048 подпись в Base64 payload. При валидации лицензии Ruxeo:

  1. Парсит структуру RXLC-{version}-{payload}-{checksum};
  2. Проверяет CRC32 checksum (защита от опечатки, не криптография — см. §6.2);
  3. Декодирует Base64 payload → JSON со значениями customer_id, expiry, ограничениями по модулям и т. п. + signature (Base64-encoded RSA);
  4. RxbmLicenseCryptoService.verifySignature(payload-без-signature, signature) проверяет подпись против embedded public key.

Private key хранится только на лицензионном сервере OTRC (издаёт ключи). Public key разворачивается на каждой инсталляции Ruxeo.

1.2 Fallback chain (iter5 §6.1)#

RxbmLicenseCryptoServiceImpl.start() загружает public key в три приоритетных шага:

  1. Inline PEM — nuxeo.conf property rxbm.licensing.crypto.public_key.pem (PEM в одну строку, newlines как \n).
  2. PEM file — nuxeo.conf property rxbm.licensing.crypto.public_key.file (абсолютный путь к файлу).
  3. Embedded DEV fallback — захардкоженный placeholder в RxbmLicenseCryptoServiceImpl.EMBEDDED_PUBLIC_KEY_PEM. На startup-е логируется WARN баннер: «Using EMBEDDED DEV-ONLY license public key…». Запуск НЕ блокируется (developer-friendly для dev/CI).

Используемый источник видим через диагностический метод getPublicKeySource() и в Ruxeo.ExportDiagnostics. Production-deployment обязан попасть в (1) или (2); продолжение работы на embedded — однозначный signal что deployment-скрипт не отработал.

2. Генерация production key pair (на лицензионном сервере)#

Однократно при первичном setup или при ротации:

# RSA-2048 private key (PEM PKCS#1)
openssl genrsa -out license-private.pem 2048

# Соответствующий public key (PEM SubjectPublicKeyInfo)
openssl rsa -in license-private.pem -pubout -out license-public.pem

# Проверить fingerprint (для журналирования факта генерации):
openssl rsa -in license-public.pem -pubin -outform DER \
  | openssl dgst -sha256 -hex

Private key:

  • Хранится в licensing.ruxeo.ru infrastructure (HSM / chmod 0400 файл с ограниченным OS-доступом).
  • Используется CLI-инструментом подписания лицензий заказчиков.
  • НЕ выкладывается в git, не передаётся по email/чатам.

Public key:

  • Не secret — но и не нужно публиковать без необходимости.
  • Распространяется через deployment-pipeline на каждую инсталляцию.

3. Развёртывание public key на инсталляции#

Выберите один из двух способов (по предпочтению ops-команды заказчика):

3.1 Способ A — файл (рекомендуется для config management)#

  1. Скопировать license-public.pem на каждую ноду в безопасное место: 
    sudo install -m 0644 -o root -g root license-public.pem /etc/ruxeo/license-public.pem
  2. Прописать путь в nuxeo.conf (на каждой ноде): 
    rxbm.licensing.crypto.public_key.file=/etc/ruxeo/license-public.pem
  3. Restart Nuxeo.

Преимущества: автоматизируется через Ansible/Salt/Puppet (стандартный file resource). Файл независим от nuxeo.conf — можно обновлять без правки конфига.

3.2 Способ B — inline в nuxeo.conf#

  1. Сконвертировать PEM в одну строку с \n escape: 
    awk '{printf "%s\\n", $0}' license-public.pem
  2. Прописать результат в nuxeo.conf: 
    rxbm.licensing.crypto.public_key.pem=-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkq...\n-----END PUBLIC KEY-----\n
  3. Restart Nuxeo.

Преимущества: одна точка конфигурации, не нужно дополнительного файла. Недостатки: длинная строка в nuxeo.conf (~450 байт для RSA-2048).

3.3 Проверка после deployment#

После restart:

  1. В логах Nuxeo должно появиться: 
    INFO  License crypto service initialized (key source: file:/etc/ruxeo/license-public.pem)
    или 
    INFO  License crypto service initialized (key source: inline:rxbm.licensing.crypto.public_key.pem)
  2. Не должно появиться: 
    WARN  Using EMBEDDED DEV-ONLY license public key...
    Если warning есть — public key не подхватился (опечатка в имени property, путь файла невалиден, файл нечитаем — см. предыдущие WARN-строки про Failed to read license public key file).
  3. Проверить через Ruxeo.ExportDiagnostics operation — поле publicKeySource должно соответствовать настроенному источнику.

4. Ротация ключа#

Ротация требуется при:

  • Подозрении на компрометацию private key (security incident).
  • Плановой ротации (рекомендация ИБ-политики заказчика — например, раз в 3 года).
  • Смене провайдера лицензирования.

4.1 Процедура#

  1. На лицензионном сервере OTRC: сгенерировать новую пару (license-private-v2.pem / license-public-v2.pem) — §2.
  2. Перевыпустить активные лицензии заказчиков, подписав их новым private key. Старые лицензионные ключи (RXLC-...) перестанут проходить verifySignature() после ротации — это by design.
  3. Распространить новый public key на инсталляции (§3) — атомарно с распространением новых лицензий.
  4. Restart Nuxeo на каждой ноде (для обновления cachedPublicKey в crypto-сервисе).
  5. Архивировать старый private key на лицензионном сервере (хранить N лет для audit историчности подписанных лицензий — стандартная compliance-практика).

4.2 Опциональное упрощение — graceful overlap#

Для крупных инсталляций (где невозможен atomic restart всех нод) можно временно поддерживать оба ключа:

  1. На лицензионном сервере подписывать новые лицензии новым private key.
  2. На инсталляции временно держать оба public key — для этого нужна нативная поддержка keyring в crypto-сервисе (currently single-key only; планируется отдельным треком).

Альтернатива: rolling restart всех нод в течение technical-maintenance окна (1-2 часа), не требующая keyring.

5. Recovery от потери private key#

Если private key утрачен (нет резервной копии, нет HSM-backup):

  • Active лицензии продолжают работать — они уже подписаны и валидируются через public key, который не теряется.
  • Новые лицензии не выпустить — нужна новая пара ключей.
  • Процедура: §4.1 — генерируется новый ключ, перевыпускаются все активные лицензии заказчиков, public key распространяется.

6. Связанные документы#