Я использую cert-manager для создания сертификатов TLS для своего приложения в Kubernetes с помощью Let’s Encrypt.
Он запущен, и я вижу «ca.crt», «tls.crt» и «tsl.key» внутри контейнера моего приложения (в /etc/letsencrypt/).
Но "ca.crt" пуст, и приложение на это жалуется (Error: Unable to load CA certificates. Check cafile "/etc/letsencrypt/ca.crt"). Два других файла выглядят как обычные сертификаты.
Что это значит?
@yasinlachini это: docs.cert-manager.io/en/latest/index.html


С cert-manager вы должны использовать контроллер nginx-ingress, который будет работать как точка доступа.
Контроллер ingress nginx создаст один балансировщик нагрузки, и вы сможете настроить там сертификат tls вашего приложения.
В модуле cert-manager нет ничего о сертификате.
поэтому настройте nginx ingress с помощью cert-manager, который поможет управлять сертификатом tls. этот сертификат будет храниться в секрете kubernetes.
Пожалуйста, следуйте этому руководству для более подробной информации:
Ингрессы работают только для HTTP-трафика, если я правильно понял. Поскольку у меня есть что-то другое (MQTT), значит ли это, что я не могу использовать для него cert-manager?
вы также можете следовать этому руководству https://dzone.com/articles/secure-communication-with-tls-and-the-mosquitto-broker
или вы можете создать сертификат, локально загрузить его в секрет kubernetes и использовать секрет при входе.
То есть вы имеете в виду, что нет другого способа, кроме как сгенерировать мой собственный сертификат CA? Хотя я мог бы повторно использовать некоторые внешние полномочия, такие как letsencrypt.
@JulienD Я не делал этого раньше для mqtt с https, только я так работал.
но если что-то вроде ssl для mqtt то лучше попробовать как сгенерировать сертификат вручную и добавить в секретку kubernetes.
Согласно документации, cafile предназначен для чего-то другого (доверенные корневые сертификаты), и, вероятно, на большинстве систем было бы правильнее использовать capath /etc/ssl/certs.
Вы можете следовать этому руководству, если у вас есть операционная система Windows: TLS. Статья о том, как разрешить Mosquitto и клиентам использовать протокол TLS.
Для установки безопасного TLS-соединения с брокером Mosquitto требуются файлы ключей и сертификатов. Создание всех этих файлов с правильными настройками — не самая простая задача, но наградой за это является безопасный способ связи с брокером MQTT.
Если вы хотите использовать сертификаты TLS, созданные с помощью службы Let's Encrypt. Вы должны знать, что текущие версии mosquitto никогда не обновляют настройки прослушивателя во время работы, поэтому при повторной генерации сертификатов сервера вам потребуется полностью перезапустить брокер.
Если вы используете DigitalOcean Kubernetes, попробуйте следовать этой инструкции: ка-нинкс, вы можете использовать Cert-Manager и входной контроллер nginx, они будут работать как certbot.
Другое решение — создать сертификат локально на вашем компьютере, а затем загрузить его в секрет kubernetes и использовать секрет при входе.
Речь идет о создании собственного ЦС («1. Создать пару ключей ЦС»). То, что я хочу, это эквивалент certbot, который работал нормально без моего беспокойства, но на Kubernetes.
@JulienD, вы можете использовать certmanager и входной контроллер nginx, чтобы он работал как certbot.
Я заметил это:
$ kubectl describe certificate iot-mysmartliving -n mqtt
...
Status:
Conditions:
...
Message: Certificate issuance in progress. Temporary certificate issued.
и связанная строка в документах:
Они объясняют, что два существующих сертификата созданы для некоторой совместимости, но они недействительны до тех пор, пока эмитент не выполнит свою работу.
Это говорит о том, что эмитент настроен неправильно.
Редактировать: да, было. Вызов DNS не удался, отладочная строка, которая помогла, была
kubectl describe challenge --all-namespaces=true
В более общем смысле,
kubectl describe clusterissuer,certificate,order,challenge --all-namespaces=true
да, можно войти внутрь кластера-эмитента или эмитента, однако вы настроили и проверили события эмитента.
Какому документу вы следуете?