Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

20.02.2017

Google
WWW CITForum.ru
С Новым годом!
2007 г.

Практическое руководство по созданию центра сертификации

Глеб Пахаренко (Gleb Pakharenko), gpaharenko at gmail com

Введение

Предполагаемой аудиторией статьи являются работники служб информационной безопасности.

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

При числе клиентов более тысячи, разнообразии приложений, которым требуются сертификаты, необходимо использовать проприетарное решение. Большинство известных вендоров предлагают качественные продукты для управления жизненным циклом сертификатов. Альтернативой OpenSSL является построение центра сертификации на основе служб Windows.

Краткая справка об инфраструктуре открытых ключей и OpenSSL

Желающим глубоко изучить теорию открытых ключей рекомендую обратиться к книге Брюса Шнайера "Прикладная криптография". Остальным предлагаю бегло напомнить основные понятия.

Существует два основных класса криптографических алгоритмов - симметричные и ассиметричные. В симметричных для шифрования и дешифрования сообщения используется один и тот же ключ. В ассиметричных разные. Тот которым расшифровывают сообщения называется закрытым ключем, ключ для шифрования называется открытым. Поэтому раздел криптографии изучающий свойства открытых ключей получил название криптография открытого ключа. С помощью открытых и закрытых ключей можно подписывать документы. Для этого рядом с ключем сохраняют данные о владельце ключа и полученный файлы называется сертификатом. Вся система взаимотношений между владельцами сертификатов построена на доверии к определенным пользователям. Их подписи общеизвестны, и они подписывают сертификаты других членов, подтверждая тем самым достоверность открытого ключа и хранящихся вместе с ним данных о владельце. Для того что бы система не была скомпрометирована, пользователи принимают только сертификаты с подписями доверенных членов. Приведем более строгую терминологию:

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

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

Центр Сертификации (Certification Authority, CA) является пакетом программного обеспечения, принимающим и обрабатывающим запросы на выдачу сертификатов, издающим сертификаты и управляющим выданными сертификатами.

Корневой сертификат - сертификат принадлежащий Центру Сертификации, с помощью которого проверяется достоверность других выданных центром сертификатов.

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

Отличительное имя (Distinguished Name, DN) - данные о владельце сертификата. Включают CN (Common Name), OU (Organization Unit), O (Organization), L (Locality), ST (State or province), C (Country name).

Электронная цифровая подпись (ЭЦП)- реквизит электронного документа предназначенный для удостоверения источника данных и защиты данного электронного документа от подделки.

Схема электронной подписи обычно включает в себя:

  • алгоритм генерации ключей пользователя;
  • функцию вычисления подписи;
  • функцию проверки подписи.

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

Для того что бы подписать документ нужно зашифровать с помощью закрытого ключа значение хеш-функции от содержимого документа. Что бы проверить подпись, нужно расшифровать с помощью открытого ключа значение подписи и убедиться, что оно равно хешу подписанного документа. Таким образом цифровая подпись, это зашифрованный хеш документа.

Ключ - это набор параметров (чисел). Он может храниться в файле. В теории клиенты должны сами генерировать свои закрытые и открытые ключи, создавать запрос на подпись открытого ключа и отправлять его в центр. На практике большинство клиентов не умеют генерировать ключи, поэтому в нашем случае Центр осуществляет данную работу. Центр может отзывать сертификат, выданный клиенту, помещая его в черный список, который регулярно передается пользователям центра. С помощью корневого сертификата, который публично доступен, пользователи могут проверять сертификаты друг друга.

Итого у центра сертификации имеется:

  • закрытый ключ
  • корневой сертификат (хранящий в себе открытый ключ);
  • список отозванных (скомпрометированных) сертификатов

У клиентов:

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

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

  1. Генерацию закрытого ключа.
  2. Генерацию открытого ключа и его подпись с помощью закрытого.

Создание обычного сертификата включает:

  1. Генерацию закрытого ключа.
  2. Создание запроса на подпись сертификата.
  3. Подпись запроса в центре сертификации о получение сертификата.

Общепринятый формат информации, содержащейся в сертификате, называется Х509. Сертификаты и ключи могут храниться в разных типах файлов. В нашем случае это будут PEM и PKCS12. PEM используется на серверах, PKCS12 - в браузерах.

OpenSSL - набор криптографических программ и библиотек - предоставляет средства для управления сертификатами и закрытыми ключами. Синтаксис вызова его функций openssl имя_команды параметры. Наиболее часто встречаемые параметры - это -in имя_файла - файл, который обрабатывается, и -text - отобразить информацию о файле в текстовом формате. Основные команды:
rsa Работа с ключами
x509 Работа с файлами сертификатов в формате PEM
pkcs12 Работа с файлами сертификатов в формате PKCS12
crl Работа со списком отозванных сертификатов

Примеры использования:

Отобразить информацию о закрытом ключе:

#openssl rsa  -text -in ca.key
Enter pass phrase for ca.key:
writing RSA key:
Private-Key: (4096 bit)
modulus:
    00:c2:3c:f1:e6:56:b6:a6:87:4c:99:56:3f:03:df:
    81:04:5b:b3:4a:40:3e:93:71:62:80:e9:3b:01:00:
    21:33:91:3c:3f:6a:79:9e:81:97:8b:f4:3a:f0:b4:
    9c:af:2f:77:de:43:34:ea:cc:76:e4:ef:c5:25:00:
    85:bc:6b:1c:b8:e7:d4:a4:8c:b5:f2:9f:4b:06:f4:

Отобразить информацию о сертификате в формате PEM:

#openssl x509 -text -in ca.crt 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            b5:b5:a9:0e:3d:ed:fb:24
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua
        Validity
            Not Before: Oct 31 13:57:31 2007 GMT
            Not After : Oct 28 13:57:31 2017 GMT
        Subject: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (4096 bit)
                Modulus (4096 bit):
                    00:c2:3c:f1:e6:56:b6:a6:87:4c:99:56:3f:03:df:
                    81:04:5b:b3:4a:40:3e:93:71:62:80:e9:3b:01:00:
                    21:33:91:3c:3f:6a:79:9e:81:97:8b:f4:3a:f0:b4:
                    9c:af:2f:77:de:43:34:ea:cc:76:e4:ef:c5:25:00:
                    85:bc:6b:1c:b8:e7:d4:a4:8c:b5:f2:9f:4b:06:f4:

Детальную информацию Вы можете получить из документации OpenSSL.

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

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

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

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

  • длина ключа корневого сертификата;
  • длина ключа серверного сертификата;
  • длина ключа клиентского сертификата;
  • срок действия корневого сертификата;
  • срок действия серверного сертификата;
  • срок действия клиентского сертификата;
  • срок действия revocation list;
  • сроки проводения резервного копирования и восстановления;
  • ответственные лица и подразделения компании, связанные с деятельностью центра сертификации;
  • пароль для корневого сертификата.

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

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

Инсталляция центра сертификации

Для создания центра будем использовать адаптированный набор скриптов, написанных Ralf S. Engelschall.

Загрузите архив по ссылке http://slil.ru/25110674.

#tar -xjf CA_clean.tar.bz2
#cd CA_clean
#export CAHOME=`pwd`
#echo ${CAHOME}

Отредактируйте файл ca.conf под свои нужды:

[req]
distinguished_name      =req_distinguished_name
x509_extensions = v3_ca
prompt = no
[req_distinguished_name]
C= UA
ST = UA
L = Kiev
O = GPAHARENKO-UA
OU = ROOTCA
CN = ca.gpaharenko.com.ua
emailAddress = gpaharenko@gpaharenko.ua
[v3_ca]
basicConstraints        = CA:true
nsComment       = "CA certificate of GPAHARENKO"
nsCertType      = sslCA, emailCA
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always

В скрипте createca.sh срок жизни сертификата равен 10 лет, вы можете изменить его в соответствии с вашей политикой. В этом же файле устанавливается длина ключа сертификата.

Генерируем корневой сертификат:

#./createca.sh
Generating RSA private key, 4096 bit long modulus
...++
.................................................................................++
e is 65537 (0x10001)
Enter pass phrase for ca.key:
Verifying - Enter pass phrase for ca.key:
Enter pass phrase for ca.key:
#

Один и тот же пароль необходимо ввести 3 раза. Создаются файлы ca.key - закрытый ключ сертификата, ca.crt - корневой сертификат, ca.pfx - для некоторых приложений может понадобиться сертификат в таком формате.

#openssl x509 -text -in ca.crt |head -15
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            b5:b5:a9:0e:3d:ed:fb:24
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua
        Validity
            Not Before: Oct 31 13:57:31 2007 GMT
            Not After : Oct 28 13:57:31 2017 GMT
        Subject: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (4096 bit)
                Modulus (4096 bit):

#openssl rsa -text -in ca.key |head -5
Enter pass phrase for ca.key:
writing RSA key
Private-Key: (4096 bit)
modulus:
    00:c2:3c:f1:e6:56:b6:a6:87:4c:99:56:3f:03:df:
    81:04:5b:b3:4a:40:3e:93:71:62:80:e9:3b:01:00:
    21:33:91:3c:3f:6a:79:9e:81:97:8b:f4:3a:f0:b4:

#openssl x509 -text -in ca.pfx -inform der |head -15
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            b5:b5:a9:0e:3d:ed:fb:24
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua
        Validity
            Not Before: Oct 31 13:57:31 2007 GMT
            Not After : Oct 28 13:57:31 2017 GMT
        Subject: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (4096 bit)
                Modulus (4096 bit):

Уточняем срок действия списка отозваных сертификатов в carevoke.config:

#cat carevoke.config |grep default_crl default_crl_days = 365

Создаем пустой пока еще revocation list:

#./createcrl.sh
Using configuration from carevoke.config
Enter pass phrase for ./ca.key:
#ls crl.pem
crl.pem
#openssl crl -text -in crl.pem |head -10
Certificate Revocation List (CRL):
        Version 1 (0x0)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: /C=UA/ST=UA/L=Kiev/O=GPAHARENKO-UA/OU=ROOTCA/CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua
        Last Update: Oct 31 14:03:21 2007 GMT
        Next Update: Oct 30 14:03:21 2008 GMT
No Revoked Certificates.
    Signature Algorithm: sha1WithRSAEncryption
#

Далее создавать серверные и клиентские сертификаты можно по следующей схеме. Создается пустая папка. В ней файл openssl.conf с шаблоном сертификата:

#cat SERVERS/sales/openssl.conf
[ req ]
        default_bits           = 1024
        distinguished_name     = req_distinguished_name
        prompt                 = no
        req_extensions      = v3_req

[ req_distinguished_name ]
        C                      = UA
        ST                    = UA
        L                      = Kiev
        O                      = GPAHARENKO-UA
        OU                    = SALES
        CN                    = sales.gpaharenko.com.ua
        emailAddress     = gpaharenko@gpaharenko.com.ua

[ v3_req ]
basicConstraints                        = CA:FALSE
subjectKeyIdentifier                    = hash

Если сертификат клиентский, необходимо также указать пароль для закрытых ключей сертфиката в файле pass. По умолчанию в pkcs12 они шифруются DES3. Создадим серверный сертификат:

#./createserver.sh SERVERS/sales/
Generating RSA private key, 1024 bit long modulus
.....++++++
...++++++
e is 65537 (0x10001)
writing RSA key
CA signing: SERVERS/sales//server.csr -> SERVERS/sales//server.crt:
Using configuration from ca.config
Enter pass phrase for ./ca.key:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'UA'
stateOrProvinceName   :PRINTABLE:'UA'
localityName          :PRINTABLE:'Kiev'
organizationName      :PRINTABLE:'GPAHARENKO-UA'
organizationalUnitName:PRINTABLE:'SALES'
commonName            :PRINTABLE:'sales.gpaharenko.ua'
emailAddress          :IA5STRING:'gpaharenko@gpaharenko.ua'
Certificate is to be certified until Oct 29 14:27:03 2012 GMT (1825 days)

Write out database with 1 new entries
Data Base Updated
CA verifying: SERVERS/sales//server.crt <-> CA cert
SERVERS/sales//server.crt: OK

Серверный сертификат server.crt:

#openssl x509 -text -in SERVERS/sales/server.crt |head -15
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=ROOTCA, CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua
        Validity
            Not Before: Oct 31 14:27:03 2007 GMT
            Not After : Oct 29 14:27:03 2012 GMT
        Subject: C=UA, ST=UA, L=Kiev, O=GPAHARENKO-UA, OU=SALES, CN=sales.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:c6:19:04:81:59:7d:12:b5:fe:f5:6a:cc:13:5b:
#

Закрытый ключ серверного сертификта server.key:

#openssl rsa -text -in SERVERS/sales/server.key |head -5
writing RSA key
Private-Key: (1024 bit)
modulus:
    00:c6:19:04:81:59:7d:12:b5:fe:f5:6a:cc:13:5b:
    18:ed:30:b0:1f:81:a3:5f:fa:40:8f:47:3f:ff:84:
    1a:36:ac:c4:02:88:e5:ce:79:f0:e2:26:e8:86:1e:

После этого можно подготовить архив со всеми необходимыми файлами и передать их системному администратору сервера:

#./bundleserver.sh SERVERS/sales/
#tar -tzf SERVERS/sales/deploy.tar.gz
SERVERS/sales//server.crt
SERVERS/sales//server.key
ca.crt
crl.pem
#

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

#echo "gpaharenko" > SERVERS/sales/gleb/pass
#./createclient.sh SERVERS/sales/gleb/
Generating a 512 bit RSA private key
......++++++++++++
...................................++++++++++++
writing new private key to 'SERVERS/sales/gleb//client.key'
-----
CA signing: SERVERS/sales/gleb//client.csr -> SERVERS/sales/gleb//client.crt:
Using configuration from ca.config
Enter pass phrase for ./ca.key:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'UA'
stateOrProvinceName   :PRINTABLE:'UA'
localityName          :PRINTABLE:'Kiev'
organizationName      :PRINTABLE:'GPAHARENKO-UA'
organizationalUnitName:PRINTABLE:'SALES'
commonName            :PRINTABLE:'gpakharenko'
emailAddress          :IA5STRING:'gpaharenko@gpaharenko.ua'
Certificate is to be certified until Oct 30 14:34:08 2008 GMT (365 days)

Write out database with 1 new entries
Data Base Updated
CA verifying: SERVERS/sales/gleb//client.crt <-> CA cert
SERVERS/sales/gleb//client.crt: OK

Кроме файлов .crt и .key создается файл pkcs12, который, в основном, используется клиентскими программами.

#openssl pkcs12 -info -in SERVERS/sales/gleb/client.p12
Enter Import Password:
MAC Iteration 2048
MAC verified OK
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
Bag Attributes
    localKeyID: 47 F2 5A 86 BB 3B BF DB BD 5C DA 87 D4 3F 27 59 67 A5 16 B8
    friendlyName: my_client_certificate
subject=/C=UA/ST=UA/L=Kiev/O=GPAHARENKO-UA/OU=SALES/CN=gpakharenko/emailAddress=
gpaharenko@gpaharenko.ua
issuer=/C=UA/ST=UA/L=Kiev/O=GPAHARENKO-UA/OU=ROOTCA/CN=ca.gpaharenko.ua/emailAdd
ress=gpaharenko@gpaharenko.ua

Упаковуем клиентский сертификат:

#./bundleclient.sh SERVERS/sales/gleb/
#tar -tzf SERVERS/sales/gleb/deploy.tar.gz
SERVERS/sales/gleb//client.p12
ca.crt
crl.pem
#

Одной из важных задач управления жизненым циклом является отзыв сертификата. Выполняется он с помощью скрипта revoke.sh

#./createclient.sh SERVERS/sales/blocked/
Generating a 512 bit RSA private key
...++++++++++++
............++++++++++++
writing new private key to 'SERVERS/sales/blocked//client.key'
-----
CA signing: SERVERS/sales/blocked//client.csr -> SERVERS/sales/blocked//client.crt:
Using configuration from ca.config
Enter pass phrase for ./ca.key:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'UA'
stateOrProvinceName   :PRINTABLE:'UA'
localityName          :PRINTABLE:'Kiev'
organizationName      :PRINTABLE:'GPAHARENKO-UA'
organizationalUnitName:PRINTABLE:'SALES'
commonName            :PRINTABLE:'blocked'
emailAddress          :IA5STRING:'gpaharenko@gpaharenko.ua'
Certificate is to be certified until Oct 31 09:50:04 2008 GMT (365 days)

Write out database with 1 new entries
Data Base Updated
CA verifying: SERVERS/sales/blocked//client.crt <-> CA cert
SERVERS/sales/blocked//client.crt: OK
#./revoke.sh SERVERS/sales/blocked/client.crt
Using configuration from carevoke.config
Enter pass phrase for ./ca.key:
Revoking Certificate 03.
Data Base Updated
Using configuration from carevoke.config
Enter pass phrase for ./ca.key:
#                               

Можем убедиться, что в обновленном файле crl.pem содержится сертификат с номером 3:

#openssl crl -text -in crl.pem | head -8
Certificate Revocation List (CRL):
        Version 1 (0x0)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: /C=UA/ST=UA/L=Kiev/O=GPAHARENKO-UA/OU=ROOTCA/CN=ca.gpaharenko.ua/emailAddress=gpaharenko@gpaharenko.ua
        Last Update: Nov  1 09:50:26 2007 GMT
        Next Update: Oct 31 09:50:26 2008 GMT
Revoked Certificates:
    Serial Number: 03
#
#openssl x509 -text -in SERVERS/sales/blocked/client.crt | head -4
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 3 (0x3)

#

Заключение

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

Необходимо подчеркнуть, что текущий набор скриптов и конфигурационных файлов можно доработать, чтобы параметры сертификатов находились только в конфигурационных файлах и уменьшилось дублирование информации.

Приложение

Краткое описание файлов:
bundleclient.sh   скрипт для упаковки необходимых для отправки клиенту файлов
bundleserver.sh скрипт для упаковки необходимых для отправки клиенту файлов
ca.conf файл с параметрами корневого сертификата
ca.crt корневой сертификат
ca.db.certs Каталог, где хранятся выданные сертификаты
ca.key закрытый ключ сертификата
ca.pfx корневой сертификат в специальном формате
carevoke.config файл с параметрами отзыва сертификатов
createca.sh скрипт создания корневого сертификата
createclient.sh скрипт создания клиентского сертфиката
createcrl.sh скрипт создания списка отозваных сертификатов
createserver.sh скрипт создания серверного сертификата
crl.pem список отозваных сертификатов
revoke.sh скрипт отзыва сертификата
sign1.sh Скрипт, подписывающий серверные сертификаты
signclient.sh Скрипт, подписывающий клиентские сертификаты

В каталоге, в котором будет лежать серверный сертификат, необходимо поместить файл с параметрами openssl.conf.

В каталоге, в котором будет лежать клиентский сертификат, необходимо поместить файл с параметрами openssl.conf и файл с паролем pass.

Ссылки

  1. Кори Хайнс (Corey Hynes). Введение в Инфраструктуру открытого ключа (PKI, Public Key Infrastructure) и Службы сертификации (Certificate Services) Windows Server 2003
  2. Инфраструктура открытого ключа. Сайт Microsoft TechNet.
  3. Red Hat Certificate System. Administrator's Guide
  4. Электронная цифровая подпись. Материал из Википедии

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...