Предварительная подготовка

Данный этап включает оценку числа клиентов, спецификацию требуемых типов сертификатов, требования к их стойкости и времени жизни. На выходе желательно получить предварительные версии Certificate Policy и Certificate Practic. Возможно, это будет один совмещенный документ. В Certificate Policy описываются общая архитектура центра сертификации, ответственные лица, процедуры первоначальной генерации корневого сертификата, резервного копирования, обстоятельства отзыва ключей, механизм передачи сертификатов клиентам (внутренним и внешним). В Certificate Statement описываются типы сертификатов, необходимые атрибуты и расширения, уточнения процедур передачи отзыва, перевыдачи, сроки жизни. Предусмотрите также действия в случае компрометации центра. Желательно систематизировать именование полей сертификатов, к примеру, в качестве OU можно использовать общепринятое название отдела. В Интернете можно найти множество примеров данных документов.

В статье у нас будет только 2 типа сертификатов: клиентский и серверный. Серверный предназначен для аутентификации веб-серверов. Клиентский используется для аутентификации клиента при доступе к веб-ресурсу.

Таким образом, в нашем конкретном случае необходимо ответить на следующее:

длина ключа корневого сертификата;

длина ключа серверного сертификата;

длина ключа клиентского сертификата;

срок действия корневого сертификата;

срок действия серверного сертификата;

срок действия клиентского сертификата;

срок действия revocation list;

сроки проводения резервного копирования и восстановления;

ответственные лица и подразделения компании, связанные с деятельностью центра сертификации;

пароль для корневого сертификата.

Рекомендую выработать общие правила для настройки авторизации X509 и параметров SSL на серверах компании. В документе можно описать разрешенные криптоалгоритмы, версии SSL, глубину верификации цепочки сертификатов, какие данные о сертификате клиента следует отображать в журналах.

Из опыта рекомендую назначить системных администраторов ответственными за внедрение, безопасное хранение, своевременное обновление серверных сертификатов данных серверов. Использование материальных носителей при передаче сертификатов создает избыточную нагрузку на ответственных за выдачу. Как вариант можно использовать разные каналы связи, сертификат по e-mail, пароль по телефону, sms. Большинство пользователей клиентских сертификатов не в состоянии самостоятельно сгенерировать запрос на подпись, поэтому ключи для них нужно создавать самим. При экспорте клиентам нужен файл в pkcs12 формате, администраторам серверов файлы ключа и сертификата в формате PEM. Необходимо следить за временем на машине центра сертификации, т.к. неточность грозит тому, что сертификат может быть недействителен некоторое время после выдачи. Компьютер центра желательно отключить от сети. Передачу сертификатов можно осуществлять на flash-носителе.