Назад | Перейти на главную страницу

Проблемы безопасности при перемещении сертификата SSL с подстановочными знаками из одного стека LAMP в другой.

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

Я намерен скопировать промежуточные и первичные сертификаты, предоставленные нашим органом SSL, в новый стек LAMP, обновить файлы конфигурации Apache, чтобы использовать новый сертификат SSL, и перезапустить мой веб-сервер.

Есть ли какие-либо проблемы безопасности, о которых мне следует знать при повторном использовании сертификата SSL, подобного этому? Я просто хочу убедиться, что не упускаю из виду что-то важное. Спасибо.

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

Теперь к вашему вопросу: кроме обеспечения безопасности вашего закрытого ключа при передаче между хостами, беспокоиться не о чем. Если вас беспокоит передача ключа и вы хотите быть ультра-параноиком, вы можете использовать gpg чтобы зашифровать ключ перед его перемещением, а затем расшифровать его на новом сервере.

Нет ничего принципиально неправильного в безопасном копировании вашего старого сертификата и ключа, если вы уверены, что понимаете разницу, как пояснил @EEAA.

Тем не менее, я считаю разумным установить практику всегда переназначение (перевыпуск) сертификата при выполнении какого-то большого шага, который затмевает дополнительные шаги настройки. Следующие 3 проблемы безопасности, о которых следует помнить при повторном использовании ваш старый ключ, но они будут смягчены, если вместо этого вы измените ключ:

  1. Чистый старт + простота: после установки на новый стек вам просто не нужно беспокоиться о потенциале предыдущие нарушения больше нет.
  2. Резервное копирование предыдущего сервера больше не должно быть проблемой с точки зрения потери ключа в будущие нарушения. (Вам все равно нужно убедиться, что нет резервных копий более старой версии, лежащих по другим причинам, кроме ключа: часто забывают, потому что с тех пор сервер переместился)
  3. Новые алгоритмы: в настоящее время не происходит соответствующего перехода, но когда снова придет время, вероятно, что автоматически обновляется вас к текущему набору ограничений (расширений) и алгоритмов хеширования. Прекращение использования SHA-1 было намного лучше, чем отказ от поддержки md5, ожидайте, что центры сертификации будут убеждать своих клиентов в обновлении быстрее в следующий раз.

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