Я настраиваю небольшую службу vpn для 10-100 экспатов, чтобы они могли получить доступ к обычно заблокированным сайтам. Я бы хотел, чтобы они могли зарегистрироваться через мой веб-сайт, который после оплаты будет генерировать их client.cert, client.key и client.conf и, возможно, tp.key и будет доставлен в безопасном, но еще не решил, метод.
Проблема в том, что для их создания мне нужны ключи ca.crt и ca.key. Предполагается, что ключ ca.key хранится запертым в сверхбезопасном месте в автономном режиме. Хранение его на моем веб-сервере, похоже, вызывает проблемы. Поскольку другие крупные провайдеры VPN, похоже, могут мгновенно сгенерировать ключи, как они это делают, сохраняя ключ в безопасном месте - или нет?
Наконец, я подумал, что, может быть, мне стоит сохранить сервер openvpn и сайт регистрации на разных серверах - это необходимо?
Я управляю несколькими службами PKI, так что это знакомая головоломка.
По возможности мы храним ключи CA на отдельном компьютере. Это внутренняя сеть нашей компании и хосты с ограниченными услугами, если таковые имеются. Процессы запроса и подписи абстрагируются друг от друга с помощью простого протокола и небольшого нажатия кнопок вручную. Со временем решения, которые мы использовали, делятся на два лагеря:
Что-то столь же простое, как HTTPS POST, который отправляет CSR на внутренний ресурс, запрашивает пароль и возвращает данные CRT обратно.
Сделанные на заказ и чуть более сложные односторонние API для получения запросов и возврата сертификатов. Который на самом деле состоит из триады систем, каждая из которых разбита для выполнения очень конкретной части жизненного цикла PKI - точки сбора данных конечным пользователем, управления лицензиями и подписания.
Честно говоря, я бы не советовал следовать последнему, если у вас нет много времени или хорошего бизнес-кейса. Вы можете повторить что-то вроде первого. В качестве альтернативы, как грызть говорит, что вы можете обнаружить, что ваш прицел даже не гарантирует этого; если вы уверены в своем веб-сервисе и решите, что ущерб не будет распространяться далеко.
Одна из причин, по которой ущерб не будет столь значительным, заключается в том, что ваш текущий план включает в себя создание личных ключей клиента самостоятельно. Это говорит о том, что в случае взлома веб-сервера, даже без ключа CA, кто-то в любом случае будет иметь доступ к действующим сертификатам клиента и связанным с ними закрытым ключам с доступом к вашим службам. Что вполне может предшествовать обеспечению безопасности вашего ЦС. В идеале клиенты должны создавать свои собственные закрытые ключи и нести ответственность за них.
У меня есть скрытое подозрение, что крупные центры сертификации, которые предоставляют «мгновенные» сертификаты SSL, вероятно, полагаются либо на круглосуточную низкооплачиваемую службу поддержки, либо (что более вероятно) просто помещают ключ CA на машину с крайне ограниченными возможностями подключения и разрешают только очень простой протокол для запроса генерации сертификата.
Учитывая, что в вашем случае вы создаете сертификат, который действителен только для вашего сайта, и у вас есть относительно небольшое количество сертификатов, которые нужно перевыпустить в худшем случае, я был бы склонен либо оставить ключ CA включенным. веб-сервер (если вы уверены, что безопасность вашей системы высока) или у вас есть вторая машина, которая хорошо защищена (нет других служб, кроме SSH, для предоставления команды подписи ключа веб-серверу), если вы не так уверен в безопасности веб-сервера.