Jump to content
Калькуляторы

Свои сертификаты для локальной зоны

Хочу собрать в кучу информацию по сертификатам и УЦ.

 

Исходные данные: провайдер дает Dual Access, в публичной сети доступ в интернет, в приватной сети доступ к внутренним ресурсам (личный кабинет, локальные ресурсы и т.п.).

Допустим адресация 10.1.0.0/16 и зона provider.local, в которой есть ряд ресурсов (users.provider.local, files.profider.local и т.п.).

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

Есть самоподписанный корневой сертификат (КС), который в офисной сети провайдера загружается политиками. Для абонентов есть инструкция, в которой описано, как этот корневой сертификат можно загрузить и установить.

Для сервисов созданы дополнительные сертификаты, удостоверенные КС. Поскольку КС у большинства пользователей добавлен в доверенные центры сертификации, то ошибок браузеры не выдают.

 

Но есть нюансы.

Сертификаты я создавал вручную (с помощью OpenSSL). С этой темой я знаком постольку поскольку, делал по инструкциям и что-то забыл или не понял. И вдобавок потерял приватную часть КС.

Теперь у сертификатов истекает срок действия. Соответственно их нужно перевыпустить. Впрочем информации по перевыпуску обычного сертификата в интернете достаточно.

Но и у КС истекает срок действия, а как перевыпустить его, чтобы он по прежнему остался доверенным, я не нашел.

 

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

Но тема УЦ достаточно обширна, в ней много тонкостей и без изучения достаточно большого объема теории с ними не разобраться.

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

Нет ли какого-то более-менее комплексного решения, которое бы позволяло создать УЦ без вникания в тонкости?

Share this post


Link to post
Share on other sites

УЦ и есть владелец КС. То, что у вас было реализовано, с ручным выпуском сертификатов как раз являлось, хоть и с большой натяжкой, УЦ.

Перевыпустить сертийикат, чтобы он остался доверенным вы не сможете, необходимо будет повторить процедуру добавления вашего КС в доверенную область на всех клиентах.

 

По сути УЦ - это владелец доверенного КС, который распространяется мантайнерами различных дистрибутивов.

Share this post


Link to post
Share on other sites

Я конечно не в теме, но это я понимаю :)

Я видимо неудачно выразился, что меня не так поняли.

Нет ли решения, чтобы выпускать сертификаты можно было из GUI-интерфейса, чтобы запросы автоматически сохранялись, сертификаты автоматически экспортировались в нужном формате и чтобы не нужно было вспоминать правильные ключи к openssl? Чтобы все типовые процедуры УЦ были автоматизированы и запускались одной кнопочкой?

 

Перевыпустить сертийикат, чтобы он остался доверенным вы не сможете, необходимо будет повторить процедуру добавления вашего КС в доверенную область на всех клиентах.

А как же это делается в случае настоящих УЦ? Ведь у них сертификаты истекут со временем. И зашитые в дистрибутиве ОС сертификаты станут недействительными.

 

И еще вопрос. Как в этом случае быть с другими сертификатами, которые были удостоверены старым корневым сертификатом? Они ведь станут недействительными.

И их все придется массово перевыпускать, удостоверяя новым корневым сертификатом. Причем этот новый корневой сертификат предварительно потребуется добавить в доверенные центры.

Как осуществляется прозрачная смена корневых сертификатов по истечению срока действия?

Share this post


Link to post
Share on other sites

Как я уже писал КС для УЦ распространяются разработчиками ОС в кач-ве обновлений.

Прозрачная замена сертификатов происходит просто их преждевременной заменой.

То есть сертификат просто заменяется заблаговременно и всё. И так происходит по цепочке.

 

А вот про GUI я вам не подскажу.

 

З.ы. я в теме тоже не гуру так что советую проверять полученную от меня информацию :)

Share this post


Link to post
Share on other sites

Прозрачная замена сертификатов происходит просто их преждевременной заменой.

Ну я так и понял.

Есть КС1, который действует с 2001 по 2030. Есть КС2, который действует с 2025 по 2070.

В период с 2025 по 2030 они действуют оба.

Но обычные сертификаты не могут быть удостоверены одновременно двумя КС.

Например, у Microsoft есть сертификат, заверенный КС1, который используется для подписывания системных файлов.

В 2026 году они этот сертификат меняют на другой, заверенный КС2.

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

 

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

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

Share this post


Link to post
Share on other sites

Нашел графические оболочки, TinyCA и XCA.

Никто с ними не работал?

Share this post


Link to post
Share on other sites

Нашел такое.

Интереснее вопрос, что делать, когда истекает срок выдачи корневого сертификата. К счастью, здесь все достаточно просто.

Главное - иметь первоначальный закрытый ключ корневого сертификата (ни в коем случае не удаляйте его!)

Итак, для перехода на новый ключ корневого сертификата нужно просто сгенерить новый ключ СА с использованием _старого_ закрытого ключа. При этом все ключи, выданные "старым" СА будут валидны.

Share this post


Link to post
Share on other sites

Пришел к неожиданному решению.

OpenSSL и скриптовая обвязка к нему это наверное более правильно.

Но для небольшого внутреннего CA удобнее оказалось использовать XCA (версию для Windows).

Share this post


Link to post
Share on other sites

Еще вопрос, где можно почитать рекомендации по созданию сертификатов, в какие поля что следует писать?

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

Читал статью и комментарии, но там информация довольно старая.

Share this post


Link to post
Share on other sites

Нашел такое.

Интереснее вопрос, что делать, когда истекает срок выдачи корневого сертификата. К счастью, здесь все достаточно просто.

Главное - иметь первоначальный закрытый ключ корневого сертификата (ни в коем случае не удаляйте его!)

Итак, для перехода на новый ключ корневого сертификата нужно просто сгенерить новый ключ СА с использованием _старого_ закрытого ключа. При этом все ключи, выданные "старым" СА будут валидны.

 

Я последнюю строчку не понял. Как сгенерить новый ключ с использованием старого? Или имеется ввиду подписывание? Да и что-то логики не вижу. Какой смысл, выпуская новый КС, подписывать его старым, который вот-вот закончится?

Share this post


Link to post
Share on other sites

Startssl.com

Годовалые сертификаты можно бесплатно сделать, с некоторыми ограничениями.

За деньги недорого делается wildcard и на несколько лет.

Мне кажется ваша морока дороже обходится

Share this post


Link to post
Share on other sites

Как сгенерить новый ключ с использованием старого?

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

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

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

 

Startssl.com

А они дадут сертификаты на домены типа provider.local?

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

Share this post


Link to post
Share on other sites

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

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

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

Что такое ключ я понимаю.

Я не понял формулировку "сгенерить новый ключ СА с использованием _старого_ закрытого ключа", имелся ввиду не "новый ключ", а "новый сертификат".

Share this post


Link to post
Share on other sites

Если хочется GUI, то есть XCA, есть TinyCA. Это если на быструю руку. Обычно центры сертификации разрабатывают свой набор софта. Если не планируется подписывать сторонние сертификаты, то покупать верифицированные сертификаты смысла нет. Ну и главное, держать в сохранности ключик корневого сертификата, ибо все дочерние подписываются ключиком, а не сертификатом. Т.е. если в будущем переподписать с проделнием срока существующий корневой, либо выпустить совершенно другой корневой на освнове существующего ключика, то все подписанные дочерние останутся действительными.

Edited by vop

Share this post


Link to post
Share on other sites

Очень рекомендую для локального центра сертификации EJBCA Community.

Share this post


Link to post
Share on other sites

А чем он лучше XCA?

По скриншотам я какой-то особой разницы не вижу.

А XCA удобна возможностью носить на флешке и запирать в сейф.

Share this post


Link to post
Share on other sites

А чем он лучше XCA?

По скриншотам я какой-то особой разницы не вижу.

А XCA удобна возможностью носить на флешке и запирать в сейф.

 

EJBCA с web-интерфейсом. Есть возможность запрашивать сертификаты клиентами (очень удобно, например, разворачивать VPN в автоматическом режиме).

Есть возможность публикации файла отзыва сертификатов и т.д.

 

XCA, если я правильно понимаю, разворачивается локально и внешнего доступа к нему нет. Но я с XCA не работал - его преимуществ не знаю.

 

Носить приватный ключ CA на флешке и работать с токенами у EJBCA тоже есть.

Share this post


Link to post
Share on other sites

некропост.

 

 

как сейчас с сертификатами? кто как решает к примеру, для аутентификации в wpa-enterprise?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this