| ||||
| ||||
| Здравствуйте, У меня вопрос такого плана: сейчас функционирует корневой УЦ, пользователям выданы сертификаты этим УЦ, но в скором времени планируется перевести этот УЦ в разряд подчиненных, то есть сертификат этому УЦ будет выдан вышестоящим УЦ. Как при этом сохранить работоспособность тех пользователей, которым уже выданы сертификаты, не проводить же поголовную замену ключей всем пользователям этого УЦ. И вообще, существует ли какая-то схема перевода УЦ с корневого на подчиненный, не переустанавливая при этом УЦ полностью и не теряя данных о зарегистрированных пользователях, т.к. насколько я понимаю, режим работы уц задается при установке службы сертификации. Заранее спасибо. | ||||
| Ответы: | ||||
| ||||
| Можно предложить следующую схему: чтобы не трогать пользователей, переподписать открытый ключ и информационную часть вашего нынешнего издателя на ключе вновь образованного корня. На самом деле это ни что иное, как образование кросс связи (форварда), но далее существует следующая организационная проблемка. Если вы строите именно подчиненность, т.е. иерархическую модель, то вам придется доверенным образом доставить на все рабочие места сертификат самоподписанного корня, если используете сетевую (или мостовую) модель, то этого делать не надо, но для этого должны быть указания для всех участников, что появилась такая связь. Если у вас есть LDAP, то все пройдет на автомате, если – нет, надо было в составе персональных сертификатов ранее прописывать AIA и информацию из него использовать при построении цепочки – это для пользователей из чужих доменов, но под самоподписанным рутом, либо им всем руками раскладывать вашего издателя. Следует также заметить, что при образовании иерархии, при построении цепочки сертификации, даже внутри вашего домена, придется по сети доставлять СОС от головного издателя, что увеличивает нагрузку на публикалище СОС на головном издателе. Причем (по любым причинам) невозможность получения СОС от самоподписанного корня приведет к обвалу всей вашей PKI системы – чем собственна и слаба иерархическая организация PKI систем. | ||||
| ||||
| По ответу Сергея Муругова. Всё так, но, технологии перевода УЦ с головного на подчинённый Вы не предложили :) Поэтому пара комментариев. Насколько я понял, хочется сохранить всех пользователей и все сертификаты так, чтобы при [плановой] смене сертификата существующего пользователя ему выдавался бы сертификат, подписанный на новом подчинённом ЦC. В рамках КриптоПро УЦ это возможно при условии, что будут параллельно работать два ЦC - старый и новый подчинённый (и третий - вышестоящий для последнего). Старый нужен для обеспечения возможности отзыва существующих сертификатов. | ||||
| ||||
| Технология очень простая - подменить сертификат издателя. Все остальное (конкретные действия или последствия) зависит от используемых техрешений, организации существующей и будущей системы, карты связей - взаимоотношений между подчиненными узлами и т.п. И встречный вопрос, зачем при отзыве старых сертификатов держать старого издателя, почему это нельзя сделать от нового? | ||||
| ||||
| Если это достижимо - почему нет. Только - не заартачится ли MS CA (предположим, используется именно он) при отзыве сертификата? | ||||
| ||||
| Еще раз, в вопросе мало информации для развернутого ответа (каков вопрос – такой и ответ), чтобы пошагово что то рекомендовать. Но технология одна – подмена издателя, где открытый ключ и информационная часть осталась от старого издателя. А уж кто там будет артачится – вопрос к тому что используется или планируется к использованию. | ||||
| ||||
| Вот несколько уточнений: при регистрации пользователей используется распределенный режим, все поьзователи в разных доменах, доступ к центру регистрации у них только через интернет. По поводу ваших ответов: Насколько я понял, чисто технически перевод УЦ в подчиненный режим нужно выполнить следующим образом: ставится новый подчиненный СА, ему головным УЦ выдается сертификат, делаем кросс-сертификацию старого корневого УЦ и головного УЦ для вновь образованного подчиненного, полученный кросс-сертификат раздается старым пользователям (каким образом это лучше сделать?), центру регистрации выдается новый сертификат, подписанный новым СА, на центре регистрации меняется URL СА на новый. Если я где-то не прав или нужны еще какие-либо уточнения, поправьте меня пожалуйста И еще попутно вопрос: Что необходимо предусмотреть перед регистрацией пользователей, если УЦ будет работать сначала как корневой, а затем как подчиненный? | ||||
Игорь