Один и тот же подстановочный сертификат AWS в разных регионах

Если вы запросите «один и тот же» сертификат в Amazon Certificate Manager более одного раза — будь то в одном и том же регионе или между регионами — вам фактически не будет выдан один и тот же идентичный сертификат несколько раз. Каждый из нескольких сертификатов будет иметь одинаковые субъекты и альтернативные имена субъектов, но на самом деле они не будут «одним и тем же» сертификатом. У них будут разные закрытые ключи и ARN.

Запрос сертификатов с одним и тем же субъектом (доменом) в разных регионах не влияет на безопасность, поскольку эти два сертификата не имеют ничего общего.

Обратите внимание: если вы используете HPKP, вам необходимо учитывать существование несколько действительных открытых ключей. Закрепление сертификатов, выданных ACM, не рекомендуется и, очевидно, , закрепление теперь устарело в любом случае.

Кроме того, обязательно используйте проверку DNS для своих сертификатов, когда это возможно, независимо от того, используете ли вы сертификаты в нескольких регионах или нет. Автоматическое ежегодное продление сертификатов может работать не так, как ожидалось, если вы используете проверку по электронной почте, особенно когда сертификаты для одного и того же домена (ов) созданы в нескольких регионах или сертификат находится в одном регионе, но является сертификатом только для домена с подстановочными знаками. В этих и других случаях вам, возможно, придется вручную подтверждать электронные письма с продлением, если вы не используете проверку DNS. (Это не ограничение службы само по себе. Для автоматического обновления сертификатов, подтвержденных по электронной почте, служба должна убедиться, что доменные имена, указанные в сертификате, действительно используют сертификат в Интернете, и ACM необходимо подтвердить это, не используя внутреннюю информацию.)

Проверка DNS была введена после того, как ACM стал доступен, поэтому, если у вас есть сертификаты, выпущенные ACM до выпуска этой функции, вам следует подумать о создании новых сертификатов с проверкой DNS и переключении на них.

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

Предположим, у вас есть 2 сертификата с разными ключами для одного и того же полного доменного имени (с подстановочным знаком или без), один в Северной Вирджинии, другой в Ирландии.

Если ваш закрытый ключ украден в Северной Вирджинии, может быть проведена атака «человек посередине» для расшифровки содержимого связи с любой из ваших служб: в Северной Вирджинии и в Ирландии. Так что наличие разных сертификатов и приватных ключей ничего не меняет.

НО, если вы используете наборы шифров без свойства PFS (см. https://en.wikipedia.org/wiki/Forward_secrecy), закрытый ключ N Virginia позволит расшифровывать сообщения только со службой N Virginia. Таким образом, в этой ситуации наличие разных сертификатов и закрытых ключей меняет ваш уровень безопасности.

В любом случае, используя AWS ELB и AWS CloudFront, AWS будет знать закрытый ключ, даже если вы решили использовать свой собственный. Таким образом, ваша безопасность не зависит от вас. Это зависит от того, как AWS защитит ваш закрытый ключ, и вы не можете получить информацию об этом: наличие общего закрытого ключа в разных регионах может или не может быть менее безопасным, чем наличие одного ключа для каждого региона.

Единственный способ использовать сервисы AWS с закрытыми ключами, неизвестными AWS, — использовать сервис CloudHSM AWS или купить себе HSM и подключить его к своему облаку AWS VPC. К сожалению, чтобы иметь веб-сервис в AWS, использующий этот сервис, вам необходимо установить веб-сервер на экземпляр EC2, поскольку CloudHSM и пользовательский HSM несовместимы ни с ELB, ни с CloudFront.

В вашей ситуации вам нужно доверять AWS.