К вашему сведению, это «вопрос мнения», на который некоторые люди не одобряют StackOverflow, но я не из тех людей, поэтому я дам вам 2 *.
Интегрированное решение против CompositeРешение
Сценарий, который вы описываете, является одной из причин, по которой я создал 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, чтобы он мог функционировать как микросервис для распространения сертификатов, и для этого не потребовалось бы много работы - но мне нужно было бы узнать больше о вашем проекте, чтобы лучшепонять)
Резюме:
- создать с помощью (wrap) certbot для каждого сервиса и синхронизировать файлы с удаленным хранилищем как микросервис
- интегрировать собственный ACME / Let'sЗашифруйте решение и синхронизируйте с плагином для хранилища, чтобы разрешить различные типы существующих служб хранилища
- создайте отдельный сервис для выдачи сертификатов, используйте api rest для каждого сервиса
Все они действительны, и в зависимости от того, какой код уже доступен, их будет довольно легкоdo.
Единственная проблема с запуском certbot в каждом экземпляре состоит в том, что может возникнуть сложность подключиться к системе, которую он использует для проверки сертификатов, чтобы вместо нее использовать удаленную службу.
Bestвыбор?
Я лично считаю, что второй вариант (интеграция кода ACME в службы и наличие подключаемой архитектуры для хранения) является наилучшим, поскольку в случае сбоя микросервиса, который обрабатывает сертификаты ACME, другие ваши службывсе еще способен получить свой собственный (поиск не удается, они получают сертификат, а не использовать существующий).Это прогрессивное улучшение.Это также то, что архитектура плагинов Greenlock прекрасно подходит для использования.
Форматы и пакеты
Некоторые могут сказать, что вы хотите иметь хранилище ключей с парольными фразами и тому подобное, используя P12, и я думаю,это действительно.
Однако, это будет уже зашифровано при передаче, и почти наверняка оно будет раскрыто таким образом, что, если ваш веб-сервер будет скомпрометирован, фраза-пароль также будет скомпрометирована, поэтому я бы предпочел использоватьпростой PEM и JWK.
В вашем случае использования кажется, что вам, вероятно, не нужен JWK, так что это будет означать просто PEM.
PEM требует только удаление пробела и комментариев, а затем декодирование изстандартный Base64, если по какой-либо причине вам нужно было декодировать его в DER вручную.Кроме того, его можно преобразовать в Base64URLSafe, удалив комментарии и пробелы, а затем заменив - на _ и / на +.
Кроме того, мне очень нравится шаблон хранения и распространения этихштук:
cert.pemchain.pemprivkey.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-сервисов.