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

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).

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

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

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

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

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

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

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

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

У клиентов:

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

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

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

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

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

Общепринятый формат информации, содержащейся в сертификате, называется Х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.