☰

Как перейти на сертификаты, управляемые Google, без простоев?

tag-icon • tag-icon ssl-certificate google-cloud-platform load-balancing google-compute-engine
Как перейти на сертификаты, управляемые Google, без простоев?

Я переношу example.com от внешнего (не Google) хостинг-провайдера в GCP.

При настройке балансировщика нагрузки я заметил, что для проверки управляемого Google сертификата мне необходимо указать example.com в балансировщике нагрузки.

Мне нужно просто изменить запись A example.com на (статический) IP-адрес нового балансировщика нагрузки — тогда он пройдет проверку.

Проблема в том, что у меня уже много трафика на example.com, запросы, которые происходят после того, как example.com начинает указывать на балансировщик нагрузки, но до проверки сертификата, будут генерировать ошибки SSL и очень недовольны пользователями.

Кто-нибудь решил эту проблему? Я знаю, что есть способыизбегать простоев, когдавращающийсясертификаты, но должен же быть какой-то способ переносить большие сайты без простоев?

решение1

Другие ответы очень хороши, но я был очень мотивирован найти способ перейти на балансировщик нагрузки GCP без планирования простоя, где мы в основном просто сидим и ждем, когда будут выпущены сертификаты. Добавляю свой собственный ответ, так как этот вопрос получил довольно много трафика, и оказывается, что простой не обязателен при некотором планировании и тестировании.

Вот как я это сделал:

  1. Выпустите временные сертификаты Let's Encrypt для example.com.
  2. Импортируйте сертификаты как самоуправляемые сертификаты.
  3. Настройте балансировщик нагрузки на использование самоуправляемых сертификатов.
  4. Обновите записи DNS, чтобы они указывали на балансировщик нагрузки.
  5. Создайте сертификаты, управляемые Google, и назначьте их каквторойсертификат, помимо самоуправляемого сертификата.
  6. Подождите, пока сертификат, управляемый Google, будет ACTIVE. Это может занять много времени. Это то, где был бы простой без самоуправляемого сертификата.
  7. Подождите 30 минут, пока сертификат распространится на все интерфейсы Google (GFE).
  8. Теперь балансировщику нагрузки назначено два сертификата. Обновите его, чтобы использовать только сертификат, управляемый Google. Готово!

Подробности

Подводя итоги проблемы: управляемые сертификаты Google требуют записи DNS, указывающей на балансировщик нагрузки с уже назначенным сертификатом, иначе они не будут выпущены. Это создает проблему, поскольку выпуск сертификата может занять до часа, и мы не хотим ошибок SSL в это время.

Обходной путь, который я нашел, состоял в том, чтобы использоватьсамоуправляемые сертификатыво время миграции и переключения на управляемые Google сертификаты, когда наш домен указывал на балансировщик нагрузки GCP и сертификаты уже были выпущены.

я использовалДавайте зашифруемсертификаты, но и другие тоже подойдут. Преимуществом этого было то, что мы уже использовали сертификаты Let's Encrypt, поэтому мне не нужно было беспокоиться осовместимость сертификатов.

Вот упрощенная версия того, что я сделал. Целевой прокси-сервер балансировщика нагрузки будет называться my-target-proxy, сертификаты будут называться lb-certificate-letsencryptи lb-certificate-managed. Доменные имена будут example.comи subdomain.example.com.

Предварительные условия:

Создайте новый сертификат для использования в качестве самоуправляемого сертификата, подписанного Let's Encrypt:

openssl genrsa -out letsencrypt.pem 2048

Создайте файл конфигурации openssl:

openssl.conf

[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements

[extension_requirements]
basicConstraints          = CA:FALSE
keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName            = @sans_list

[dn_requirements]
countryName               = Country Name (2 letter code)
stateOrProvinceName       = State or Province Name (full name)
localityName              = Locality Name (eg, city)
0.organizationName        = Organization Name (eg, company)
organizationalUnitName    = Organizational Unit Name (eg, section)
commonName                = Common Name (e.g. server FQDN or YOUR name)
emailAddress              = Email Address

[sans_list]
DNS.1                     = example.com
DNS.2                     = subdomain.example.com

Сгенерироватьзапрос на подпись сертификата:

openssl req -new -key letsencrypt.pem -out letsencrypt.csr -config openssl.conf

Получите подписанный сертификат от Let's Encrypt:

certbot certonly --csr letsencrypt.csr --manual --preferred-challenges dns

Обновите записи DNS, указанные certbot, чтобы подтвердить право собственности. Другие вызовы тоже могут сработать, но DNS показался самым простым.

Запишите, какой файл представляет собой полную цепочку сертификатов, и 0003_chain.pemпри необходимости замените в примере:

Полная цепочка сертификатов сохранена по адресу: ...

Загрузите и создайте самоуправляемый сертификат в GCP:

gcloud compute ssl-certificates create lb-certificate-letsencrypt \
  --certificate=0003_chain.pem \
  --private-key=letsencrypt.pem \
  --global

Создайте балансировщик нагрузки, на который вы переходите, или настройте его для использования самоуправляемого сертификата:

gcloud beta compute target-https-proxies create my-target-proxy \
  --ssl-certificates=lb-certificate-letsencrypt [url-map and other options]
# Or
gcloud beta compute target-https-proxies update my-target-proxy \
  --ssl-certificates=lb-certificate-letsencrypt

Обновите записи DNS, чтобы они указывали на IP вашего балансировщика нагрузки. Теперь он должен иметь возможность прерывать TLS для example.com и subdomain.example.com. Вы можете проверить этот шаг, добавив запись для example.com в свой файл hosts, указывающую на IP балансировщика нагрузки. Ответ Джона Хэнли дает много хороших советов по этому поводу.

Создайте управляемый сертификат:

gcloud compute ssl-certificates create lb-certificate-managed \
  --domains=example.com,subdomain.example.com \
  --global

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

Назначьте его целевому прокси-серверу.вместес самоуправляемым сертификатом. Сертификаты не будут предоставлены, пока они не будут назначены прокси:

gcloud beta compute target-https-proxies update my-target-proxy \
  --ssl-certificates=lb-certificate-letsencrypt,lb-certificate-managed

Проверьте статус:

gcloud compute ssl-certificates describe lb-certificate-managed

Подождите, пока statusне изменится с PROVISIONINGна ACTIVE-любой другой статус— это ошибка, которую следует расследовать. «Предоставление сертификата, управляемого Google, может занять до 60 минут».согласно документам(Let's Encrypt делает то же самое за считанные секунды...).

Может потребоваться еще 30 минут, чтобы он стал доступен для использования балансировщиком нагрузки.

Поэтому,подождите 30 минутпосле изменения статуса на ACTIVE.

Обновите целевой прокси-сервер, чтобы использовать только сертификат, управляемый Google:

gcloud beta compute target-https-proxies update my-target-proxy \
  --ssl-certificates=lb-certificate-managed

Распространение новой настройки может занять некоторое время. Проверьте эмитента для конечной точки в браузере или с помощью openssl:

openssl s_client -connect example.com:443 -showcerts \
  -CAfile /etc/ssl/certs/ca-certificates.crt <<< Q

Эмитентом теперь должно быть «Google Trust Services LLC» вместо «Let's Encrypt».

Самостоятельно управляемый сертификат Let's Encrypt теперь можно удалить или сохранить до истечения срока его действия на случай возникновения каких-либо проблем с управляемым сертификатом.

Чтобы очистить неиспользуемый самоуправляемый сертификат Let's Encrypt, выполните:

gcloud compute ssl-certificates delete lb-certificate-letsencrypt

решение2

У вас будет время простоя.

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

Однако я не знаю дизайн вашего сайта, использование файлов cookie, аутентификацию, управление сеансами и т. д. Могут быть сбои, которых невозможно избежать. Если возможно, рассмотрите возможность отправки клиентам электронного письма с предупреждением о техническом обслуживании сайта заранее.

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

  1. Помните, что записи ресурсов DNS кэшируются глобально. TTL записи ресурса дает подсказку о том, как долго. DNS-резолверы могут свободно использовать собственную интерпретацию вашего TTL.

  2. Запишите TTL записей ресурсов, которые вы будете изменять. Теперь измените TTL на короткое значение, например, на 1 минуту.

  3. Прежде чем вносить окончательные изменения, дождитесь истечения как минимум старого срока действия TTL.

  4. Настройте свои службы и балансировщик нагрузки перед внесением любых изменений в DNS. Убедитесь, что службы работают правильно, используя только IP-адрес. Если вы перенаправляете IP на домен или HTTP на HTTPS, временно отключите эти функции и включите их позже.

  5. Используйте certbot в ручном режиме и создайте сертификат, который можно загрузить в балансировщик нагрузки. Это устраняет этап создания SSL-сертификата балансировщиком нагрузки и ожидания проверки. Позже вы сможете переключиться на Google Managed SSL.

  6. Настройте оба фронтенда Google Cloud Load Balancer HTTP и HTTPS. Настройте SSL-сертификат Let's Encrypt во фронтенде.

  7. Планируйте оставить старый сайт работающим примерно на 30 дней после миграции. Обычно я вижу трафик на старом сайте в течение нескольких недель после миграции.

  8. Выберите время суток или день недели с наименьшим объемом трафика. Затем переключите записи ресурсов DNS. Помните, что старое значение TTL должно было истечь, чтобы новое значение TTL использовалось для кэширования.

  9. Через несколько дней, убедившись, что все работает, установите нормальные значения TTL, например:604800что является числом секунд в одной неделе или 86400 (один день). Повторно включите перенаправление сайта (IP -> домен, HTTP -> HTTPS), если используется.

решение3

В дополнение к предыдущим предложениям имейте в виду, что управляемые Google SSL-сертификаты не поддерживаются для региональных внешних балансировщиков нагрузки HTTP(S) и внутренних балансировщиков нагрузки HTTP(S). Для этих балансировщиков нагрузки вам нужно будет использовать самоуправляемые SSL-сертификаты. Я не видел, какой тип балансировщика нагрузки вы используете, однако перед тем, как попытаться настроить эту миграцию, вам нужно будет это учесть. Кроме того, в этом жегидвы можете увидеть, как создавать и использовать SSL-сертификаты, управляемые Google, а также рекомендации по обеспечению их корректной работы.1.

Я бы рекомендовал вам установить окно обслуживания для этих изменений, поскольку может пройти до 30 минут, прежде чем сертификат станет доступен для всех интерфейсов Google (GFE).

Кроме того, вздесь вы увидите официальное руководство с пошаговыми инструкциями по достижению этого поведения.

1 https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs

2 https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs#migrating-ssl

Связанный контент