Перейти к содержимому
Калькуляторы

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

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

 

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нашел такое.

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нашел такое.

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Startssl.com

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

Startssl.com

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Там цитата была. Я именно так и понял.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Использовал XCA для своих сертификатов (самоподписанных), информацию брал отсюда - http://habrahabr.ru/post/122537/

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем vop

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

некропост.

 

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.