Почему использование сертификата, созданного с помощью инструмента MakeCert, в продакшене — это плохо?

Спросите себя, что подтверждает сертификат.

Если вы получаете сертификат, выданный авторитетным ЦС, это доказывает, что владелец сертификата подтвердил свою личность в этом ЦС в соответствии с их стандартами подтверждения.

Если вы получаете сертификат, выданный специальным ЦС, это доказывает, что кто-то знает, как создавать сертификаты.

Если вы контролируете оба конца разговора, я думаю, что для этой цели можно иметь собственный частный ЦС. Вы бы доверяли своему собственному ЦС. Вероятно, вы можете сделать это действительно очень безопасным (сохранив закрытый ключ ЦС в безопасном месте в автономном режиме и сделав подписание упражнением в сникернете).

Сложность была бы в том случае, если бы вам нужно было убедить кого-то еще доверять вашему ЦС. Почему они должны? Вам нужно будет убедить их, что это безопасно, и у них будут административные накладные расходы на добавление вашего сертификата ЦС к своим клиентам.

Поскольку вы используете сертификат только для защиты сетевого трафика, а не для аутентификации пользователей/компьютеров, похоже, что у вас есть законное использование MakeCert.exe.

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

Рассмотрим эти моменты:

• (Почти) Все версии Windows Server включают службы сервера сертификатов бесплатно.
• Windows Stand-Alone CA Server чрезвычайно прост в установке и настройке.
• Windows Stand-Alone CA Server можно установить на виртуальную машину и включать/выключать всякий раз, когда вам нужно выпустить дополнительный сертификат
• Автономный сервер ЦС Windows на базе виртуальной машины может работать с очень небольшим объемом памяти (например, 256 МБ).
• Windows Stand-Alone CA Server включает удобный и понятный веб-интерфейс для регистрации, упрощающий запрос сертификатов.
• Проверка CRL может использоваться или не использоваться, в зависимости от ваших потребностей.

В прошлом я сначала начал с selfssl.exe и в конечном итоге перешел на MakeCert.exe для создания корневого сертификата, а затем выдал сертификаты для своих клиентов. Но после борьбы с синтаксисом и постоянной необходимости помнить, куда я поместил этот корневой сертификат, я переключился на использование автономного корневого центра сертификации на виртуальной машине.

ЕСЛИ сертификаты передаются только внутри, между вашими собственными серверами (и не используются клиентом так или иначе) - тогда вполне приемлемо использовать ваш собственный внутренний ЦС.
ОДНАКО, одно предложение - не иметь ваш корневой ЦС выдает сертификаты вашего провайдера. Вместо этого используйте свой корневой ЦС для создания промежуточного ЦС, а затем используйте его для выдачи сертификатов провайдера. Это поможет вам в долгосрочной перспективе, когда вам нужно будет начать управлять истечением срока действия сертификата, расширением системы/инфраструктуры, списками отзыва и т. д.

Нет никакой реальной проблемы с использованием самоподписанного сертификата в частном порядке, то есть когда вы контролируете все системы, которым необходимо доверять корневому сертификату homebrew.

Вы вручную устанавливаете свой корневой сертификат на каждую из систем, которые должны ему доверять.

Вы можете сделать это и в рабочей среде, и для использования в браузере — например, в организации, где корневой ЦС может быть развернут с помощью метода распространения программного обеспечения — нет причин идти на оплату центра сертификации, которому Microsoft доверяет.

[править] С точки зрения безопасности проблема заключается в том, чтобы содержать закрытый ключ для вашего корневого сертификата, если вы можете гарантировать, что он остается закрытым, тогда вы можете проверить любой сертификат вне этого корня.