К вашему сведению, это «вопрос мнения», который некоторые люди не одобряют в StackOverflow, но я не один из таких людей, поэтому я дам вам свои 2 цента.

Интегрированное решение против составного решения

Сценарий, который вы описываете, является одной из причин, по которой я создал Greenlock.js (набор клиентской библиотеки ACME / Let's Encrypt, cli и веб-сервера).

Мне нужно было полностью интегрированное решение, которое могло бы автоматически предоставлять сертификаты без ручного вмешательства (кроме того, в то время certbot было очень сложно установить и использовал так много оперативной памяти, что я не мог использовать его на устройствах IoT, с которыми я работал).

В моем случае я создал систему плагинов, позволяющую использовать различные механизмы хранения (fs, redis, sql, aws s3, azure storage и т. д.), А затем другие авторы предоставили большую часть этих механизмов.

Похоже, certbot, вероятно, будет работать для вас как составное решение (обертывание его), но если вы собираетесь столкнуться с проблемой создания хранилищ сертификатов и т. д., Вы также можете интегрироваться с библиотекой Java ACME (просто убедитесь, что он поддерживает ACME draft 11 / Let's Encrypt v02).

Еще одна мысль - использовать что-то вроде Greenlock в качестве интерфейса https, который обращает прокси в ваше приложение (хотя Greenlock может не соответствовать вашим потребностям - решение java или go, если оно существует, может работать лучше для вас из-за звука из него).

(Мне также кажется интересным создание некоторых REST API вокруг Greenlock, чтобы позволить ему функционировать как микросервис для распространения сертификатов, и для этого не потребуется много работы, но мне нужно будет узнать больше о вашем проекте. чтобы лучше понять)

Резюме:

• составлять (переносить) certbot для каждой службы и синхронизировать файлы с удаленным хранилищем в качестве микросервиса
• интегрировать собственное решение ACME / Let's Encrypt и синхронизировать с плагином для хранения, чтобы разрешить различные типы существующих служб хранения
• создать отдельную службу для обработки выдачи сертификатов, использовать rest api для каждой службы

Все они действительны, и в зависимости от того, какой код уже доступен, их все будет довольно легко выполнить.

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

Лучший выбор?

Я лично считаю, что второй вариант (интеграция кода ACME в службы и наличие архитектуры плагинов для хранения) является лучшим, потому что в случае сбоя микросервиса, обрабатывающего сертификаты ACME, другие ваши службы по-прежнему могут получить свои собственные ( поиск не выполняется, они получают сертификат, а не используют существующий). Это прогрессивное улучшение. Это также то, для чего неплохо поддается архитектура плагинов Greenlock.

Форматы и пакеты

Кто-то может сказать, что вы хотите иметь хранилище ключей с паролями и т.п., используя P12, и я думаю, что это действительно так.

Однако он уже будет зашифрован при передаче и почти наверняка будет раскрыт таким образом, что, если ваш веб-сервер будет скомпрометирован, кодовая фраза также будет скомпрометирована, поэтому я бы предпочел использовать простые PEM и JWK.

В вашем случае это звучит так, будто вам, вероятно, не нужен JWK, так что это будет означать только PEM.

PEM требует только удаления пробелов и комментариев, а затем декодирования из стандартного Base64, если по какой-либо причине вам нужно было декодировать его в DER вручную. Точно так же его можно преобразовать в Base64URLSafe, удалив комментарии и пробелы, а затем заменив - на _ и / на +.

Также мне очень нравится схема хранения и распределения этих произведений:

• cert.pem
• chain.pem
• privkey.pem

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

• fullchain.pem (cert.pem + chain.pem) для Apache, Nginx, Node и т. д.
• bundle.pem (fullchain.pem + privkey.pem) для HAProxy

Итак, я бы сказал, отправьте объект JSON с помощью PEM:

{ "cert": "..."
, "chain": "..."
, "privkey": "..."
}

А затем позвольте клиенту выполнить response.cert + '\\r\\n' + response.chain и т. д., Чтобы построить fullchain.pem или bundle.pem по мере необходимости.

Лучший выбор?

Все, что является самым простым и переносимым - возможно, PEM, затем JWK, затем, возможно, Base64URLSafe, но не пользовательский формат для какой-либо конкретной библиотеки Java. В будущем вы можете расширить поддержку сервисов, отличных от Java.