Сервис Fabric несколько защищенных SSL WebAPI и опрокидывание сертификатов

Question

У меня есть два приложения WebAPI в моем кластере. Оба приложения работают на каждом узле. Оба используют ядро ​​asp.net и Weblistener. Следуя советам here, я установил их для прослушивания http и https на порт 80 и 443 соответственно.

Https защищен с использованием того же сертификата и настроен с использованием связывания конечных точек (?), Как обсуждалось here. Я получил это нормально с самоподписанным сертификатом, но возникла проблема, когда дело доходило до смены сертификата на правильное. Эффективное моделирование опроса сертификата.

Я добавил новый сертификат в хранилище ключей и развернул его в кластере. Когда дело дошло до переиздания моих приложений, с новой ссылкой на сертификат, она потерпит неудачу с this ошибкой ConfigurePortCertificate: httpsPort=443, certStoreName My, certfindvalue {SSLCertFingerPrint}, error AlreadyExists. Какой вид имеет смысл сейчас ..

Поскольку оба приложения работают на каждом узле, и мы пытаемся обновить одну из них происходит следующее:

1. WebAPI1 имеет Cert_A связанный с https: 443.
2. WebAPI2 имеет сертификат Cert_A, связанный с https: 443 (это нормально, они являются тем же сертификатом)
3. Попытка обновления WebAPI1 с помощью Cert_B.
4. Издает в кластер, попытка связать Cert_B с https: 443
5. Ошибки, потому что другой сертификат (Cert_A) уже связан с https: 443

Единственным способом решения проблемой я нашел для этого принять каждый система, которая использует Cert_A на https: 443 в автономном режиме и повторно публикует все приложения, используя новый Cert_B.

Это довольно неприемлемо (как я, очевидно, что-то не так), чтобы вынудить основные части системы сменить сертификаты.

Какие у меня варианты?

Удаляет ли Kestrel https по-другому? Если бы я столкнулся с подобными проблемами, сделав что-то вроде ... вместо того, чтобы иметь сертификаты, размещенные локально (т. Е. Через предоставление виртуальных машин), я мог бы запросить последний сертификат из keyvault. Я мог бы предоставить Kestrel сертификат, предоставленный неверсированным URL-адресом в ключевое хранилище (которое получает последний сертификат). Тогда я полагаю, что все, что мне нужно сделать, это заставить службы перезапустить (например, опубликовать обновление), и они начнут использовать новейший сертификат. Тем не менее, я понимаю, что Kestrel - это not currently "supported", который будет использоваться для внешних веб-серверов.

Я был бы лучше с любой

1. Использование gatewaty (например, шлюз приложений) и хостинг все мои Weblistener услуги на разных портах, обеспеченных HTTPS
2. Использование шлюза и использовать Kestrel, либо другим или те же порты
3. Используя защищенный шлюз https и выполняйте мои службы на разных портах, не беспокойтесь о https внутри.

Или есть простое решение моей проблемы, которое я не понимаю?

Заранее благодарен!

Приносим извинения за неправильную терминологию, пожалуйста, исправьте меня.

Answer 1

В ASF есть reverse proxy. Он может быть настроен на использование SSL и завершение SSL. Это очень простое решение.

http (s): Обратный прокси-сервер может быть настроен для приема трафика HTTP или HTTPS . В случае трафика HTTPS завершение SSL происходит в обратном прокси . Запросы, которые перенаправляются обратным прокси-сервером на услуг в кластере, превышают http. Обратите внимание, что HTTPS-сервисы - , которые в настоящее время не поддерживаются.