Openssl центр сертификации windows

Введение

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

В данной статье рассмотрены детали
построения и сопровождения собственного центра сертификации на основе
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 — отобразить информацию о
файле в текстовом формате. Основные команды:

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

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

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

#

Заключение

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

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

Приложение

Краткое описание файлов:

В каталоге, в котором будет лежать серверный сертификат, необходимо поместить
файл с параметрами
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. Электронная цифровая подпись. Материал из Википедии

В статье рассказывается:

Разговор о центре сертификации логично начать с PKI — инфраструктуры открытых ключей. Находим определение в Википедии: «PKI — набор средств (технических, материальных, людских и т. д.), распределённых служб и компонентов, в совокупности используемых для поддержки криптозадач на основе закрытого и открытого ключей». Так что к PKI стоит относиться именно как к инфраструктуре, в состав которой входят те или иные компоненты.

По сути, PKI представляет собой систему, которая используется для создания, хранения и распределения цифровых сертификатов. Они, в свою очередь, должны максимально защищённым образом удостоверять, что определённый публичный ключ принадлежит той или иной сущности.

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

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

В систему PKI обычно входят:

• Центр сертификации (англ. Certificate Authority (CA)), которому будет посвящена основная часть этой статьи. Он непосредственно работает с сертификатом — выписывает, хранит, проверяет подлинность.
• Центр сертификации не следует путать с удостоверяющим центром. Также отдельно рассматривается «корневой центр сертификации» — сторона, чья честность неоспорима, а открытый ключ широко известен.
• Регистрационный центр (англ. Registration Authority (RA)). Согласно Википедии, «удостоверяющий центр доверяет регистрационному проверку информации о субъекте». Поэтому часто регистрационный центр полностью или частично объединяют с CA.
• Сертификат (англ. Certificate) — публичный ключ и идентификаторы сущности, имеющие подпись центра сертификации. В качестве идентификатора может выступать электронная почта пользователя. Если ЦС подписывает набор данных, который состоит из имени пользователя, его публичного ключа и электронной почты, то он как бы гарантирует, что эти данные подлинные. Далее под термином «сертификат» мы будем понимать сертификат стандарта X.509.
• Certificate Signing Request (CSR). По сути это запрос на подпись сертификата. В запросе обычно указывается сущность, её параметры и публичный ключ.
• Certificate Revocation List (CRL), он же список отзывов, или отозванных сертификатов. По этому списку ЦС ведёт учёт «плохих» сертификатов. И если такой сертификат используется, то ЦС не подтвердит к нему доверие. Чаще всего причина — утрата ключей сертификата.

Для базового понимания структуры PKI этого списка достаточно. Теперь рассмотрим, как всё это применяется.

Центры сертификации: как они используются

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

Допустим, условная сущность Аlice имеет сертификат, подписанный ЦС Comp, а сущность Bob пытается проверить подлинность этого сертификата. Проверка будет успешной, если Bob и Alice доверяют одному и тому же ЦС. Для решения такой проблемы в ОС Alice и ОС Bob установлено множество сертификатов различных ЦС.

Установив сертификат ЦС в систему, можно доверять тем сертификатам, которые он подписал. Если сертификат (в частности для HTTPS) выдан, но не подписан каким-нибудь доверенным ЦС, то его называют самоподписанным и он считается недоверенным — если, конечно, не заставить систему доверять такому сертификату.

Здесь могут возникать разные ошибки. Протестировать реакцию браузера на нарушения в работе SSL можно на сайте badssl.com.

Рассмотрим, как браузер реагирует на разные сертификаты. У Firefox, например, для идентификации есть такой набор сертификатов ЦС:

Вот пример с HTTPS. Есть ресурс www.geekbrains.ru, соединение с которым браузер считает доверенным:

Картинка с сайта: gb.ru

Если открыть подробности, то можно увидеть почему:

Картинка с сайта: gb.ru

Браузер считает подключение доверенным потому, что сертификат HTTPS подписан ЦС Comodo CA. Эта организация своим сертификатом подтверждает, что сертификату, выданному для сайта GeekBrains, можно доверять. Получается примерно такая схема:

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

Если коротко, то для успешной проверки доверия (в рамках HTTPS) с использованием центра сертификации необходимо, чтобы:

• в системе были соответствующие корневые сертификаты ЦС, которые будут использоваться для подтверждения сертификата конкретного сайта;
• у выданных для сайтов сертификатов не было ошибок.

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

Картинка с сайта: gb.ru

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

Скачать
файл

Другой пример — сайт wrong.host.badssl.com. Сертификат выдан для другого хоста, о чём и уведомляет браузер:

Картинка с сайта: gb.ru

А вот пример для сайта, у которого истёк срок действия сертификата:

Картинка с сайта: gb.ru

Как проверяется доверие на практике?

Для каждого сертификата в соответствии с его назначением определяется хранилище в системе — туда его можно установить вручную. Например, есть хранилище доверенных сертификатов: если поместить в него сертификат, то система будет доверять ему.

В Windows сертификаты можно просмотреть через оснастку certmgr.msc:

Картинка с сайта: gb.ru

Если поместить сертификат в хранилище «Доверенные корневые центры сертификации», то такому центру система будет доверять. А поскольку это хранилище корневых центров сертификации, система потом будет доверять и всем объектам, которые подписаны этим сертификатом.

В ОС Ubuntu Linux сертификаты хранятся в каталоге /etc/ssl/cetrs. Причём часть из них — ссылки на другой объект:

Картинка с сайта: gb.ru

Разворачиваем собственный ЦС

Чтобы лучше понять все процессы, лежащие в основе PKI, рассмотрим на практике развёртывание небольшого ЦС на виртуальной машине под управлением Ubuntu 18 (без выхода в глобальную сеть). Мы не будем жёстко придерживаться правил и стандартов выдачи сертификатов — просто разберём работу с ними.

С учетом того, что. все эксперименты мы проводим в виртуальной среде (без выхода в глобальную сеть), мы можем использовать любое доменное имя — например www.simple.org. Однако надо помнить, что в глобальной сети такое имя вполне может быть зарегистрировано за каким-нибудь сайтом.

Допустим, нам надо настроить веб-сервер так, чтобы соединение к нему шло по протоколу HTTPS и сервер заодно проверял клиента по сертификату. Пользователь у нас один, веб-сервер на Apache 2. Схема нашего центра сертификации будет такой:

Картинка с сайта: gb.ru

Начальные настройки

Сперва заполним файл /root/.rnd, который используется как источник начальных случайных значений в генераторе псевдослучайных чисел OpenSSL. Суть использования этого файла описана на сайте OpenSSL. Нам надо заполнить свой файл случайными данными, как вариант — скопировав из /dev/urandom 32768 байт в файл .rnd таким образом:

Картинка с сайта: gb.ru

Далее создадим сертификат для CA:

root@shpc:/opt/simple_CA# openssl req -newkey rsa:4096 -keyform PEM -keyout ca.key -x509 -days 3650 -outform PEM -out ca.cer


        

          Картинка с сайта: gb.ru
        
      

Опции для сертификата берутся из файла /etc/ssl/openssl.cnf. Сам файл довольно большой, мы не будем приводить здесь его содержимое. В реальности стоит создать свой конфигурационный файл с необходимыми опциями и блоками — и использовать его для генерации сертификатов.

Дарим скидку от 60%
на обучение «Программист Java» до 18 мая

Уже через 9 месяцев сможете устроиться на работу с доходом от 150 000 рублей

Забронировать скидку

Картинка с сайта: gb.ru

На выходе получим два файла: ключ и сертификат.

Картинка с сайта: gb.ru

Оба файла надо беречь. Если они попадут к злоумышленнику, он сможет использовать их для генерации сертификатов. Посмотреть сертификат можно при помощи этой команды (вывод обрезан для краткости):

root@shpc:/opt/simple_CA# openssl x509 -text -noout -in ca.cer


        

          Картинка с сайта: gb.ru
        
      

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

root@shpc:/opt/simple_CA# openssl genrsa -out server.key 4096


        

          Картинка с сайта: gb.ru
        
      

Теперь используем этот ключ для генерации запроса на выдачу сертификата (CSR):

root@shpc:/opt/simple_CA# openssl req -new -key server.key -out server.req -sha256


        

          Картинка с сайта: gb.ru
        
      
Отметим, что данные, которые вы вводите в поля, должны совпадать со значениями в тех полях, что указывались при создании сертификата корневого сервера. Теперь возьмём корневой сертификат CA и запрос — и сгенерируем на их основе сертификат для сервера:

root@shpc:/opt/simple_CA# openssl x509 -req -in server.req -CA ca.cer -CAkey ca.key -set_serial 100 -extensions server -days 1460 -outform PEM -out server.cer -sha256

        

          Картинка с сайта: gb.ru
        
      
Должно получиться 5 файлов.


        

          Картинка с сайта: gb.ru
        
      

Файл server.req можно удалить — а при необходимости создать заново. Теперь надо перенастроить веб-сервер для работы с сертификатами.

Настройка Apache 2 для использования сертификатов

Переходим в каталог /etc/apache2:

root@shpc:/mnt# cd /etc/apache2/

Создаём каталог для хранения сертификатов:

root@shpc:/etc/apache2# mkdir ssl

Включаем модуль SSL для веб-сервера. Тестирование проводилось на ОС Ubuntu Linux, поэтому модуль достаточно просто включить:

a2enmod headers

Перезапускаем веб-сервер:

root@shpc:/etc/apache2# systemctl restart apache2

Аналогично нужно включить поддержку заголовков:

Теперь создадим конфигурационный файл для модуля SSL. Пример содержимого для него можно взять на Syslink.pl. Команды такие:

root@shpc:/mnt# cd /etc/apache2/conf-available
root@shpc:/etc/apache2/conf-available# nano ssl-params.conf

Сам файл будет содержать следующие параметры (чтобы было проще работать, мы отключили заголовки Strict-Transport-Securrity, X-Frame-Options и X-Content-Type-Options):

Картинка с сайта: gb.ru

Далее созданный конфиг надо активировать:

root@shpc:/etc/apache2/conf-available# a2enconf ssl-params

Теперь переходим в каталог /etc/apache2/sites-available:

root@shpc:/etc/apache2/conf-available# cd /etc/apache2/sites-available

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

root@shpc:/etc/apache2/sites-available# cp 000-default.conf 000-default.conf.bak
root@shpc:/etc/apache2/sites-available# cp default-ssl.conf default-ssl.conf.bak

Теперь ещё раз проверяем подключённые модули headers и SSL:

Картинка с сайта: gb.ru

Далее нам надо перенести созданные сертификаты (сертификат CA и сертификат сервера) в каталог /etc/ssl/certs, а ключ сертификата сервера — в каталог /etc/ssl/private:

root@shpc:/opt/simple_CA# cp ca.cer /etc/ssl/certs/
root@shpc:/opt/simple_CA# cp server.cer /etc/ssl/certs/server.crt
root@shpc:/opt/simple_CA# cp server.key /etc/ssl/private/server.key

Далее откроем конфиг сайта (/etc/apache2/sites-available/000-default-ssl.conf) и добавим туда следующие опции:

SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key
SSLCACertificateFile /etc/ssl/certs/ca.cer

Теперь перезагружаем веб-сервер:

root@shpc:/etc/apache2# a2ensite default-ssl
root@shpc:/etc/apache2/sites-available# service apache2 restart

Проверяем доступность сайта:

Картинка с сайта: gb.ru

Видим, что Firefox не может проверить сертификат сайта. Чтобы смог, надо импортировать цепочку сертификатов, подтверждающих сертификат сервера, в список доверенных. Создадим цепочку:

root@shpc:/opt/simple_CA# openssl crl2pkcs7 -nocrl -certfile ca.cer -certfile server.cer -out serve-and-ca-chain.p7c -outform der

У полученного файла не забываем сменить атрибуты на 555:

root@shpc:/opt/simple_CA# chmod 555 serve-and-ca-chain.p7c 


        

          Картинка с сайта: gb.ru
        
      
Теперь откроем в браузере менеджер сертификатов и импортируем полученную цепочку (кнопка Import):


        

          Картинка с сайта: gb.ru
        
      
Далее можно просмотреть сертификаты и настроить доверие — вдруг что-то упущено:

        

          Картинка с сайта: gb.ru
        
      
Когда сертификаты добавлены в список доверенных, можно снова зайти на сайт и увидеть, что соединение помечается как доверенное:

        

          Картинка с сайта: gb.ru
        
      

Сейчас время настроить аутентификацию для клиентов.

Настройка аутентификации клиентов

Веб-сервер Apache поддерживает аутентификацию клиента. Это значит, что мы можем выписать клиенту сертификат SSL, а сервер сможет его проверить. Если у пользователя не будет сертификата — аутентификация не пройдёт. Для активации такой возможности надо добавить в конфиг default-ssl.conf такие опции:

SSLCACertificateFile /opt/simple_CA/ca.cer 
SSLVerifyClient require 
SSLVerifyDepth 2

После этого к сайту сможет подключиться только тот пользователь, сертификат которого:

• установлен в браузере, если клиентом является браузер, — тогда сертификат будет предъявлен при подключении к серверу;
• подписан сертификатом доверенного УЦ.

Сначала сгенерируем сертификат для клиента. Первым делом создаём ключ:

root@shpc:/opt/simple_CA# openssl genrsa -out client.key 4096

Затем на основе ключа сгенерируем CSR:

root@shpc:/opt/simple_CA# openssl req -new -key client.key -out client.req

Теперь на базе запроса сгенерируем сам сертификат:

root@shpc:/opt/simple_CA# openssl req -new -key client.key -out client.req

И импортируем сертификат в формате p12:

root@shpc:/opt/simple_CA# openssl pkcs12 -export -inkey client.key -in client.cer -out client.p12

В итоге у нас должен получиться файл client.p12. Нужно поменять права на файл, иначе сертификат не импортируется:

root@shpc:/opt/simple_CA# chmod 555 client.p12

        

          Картинка с сайта: gb.ru
        
      
Теперь можно импортировать его в браузер по аналогии с корневыми сертификатами:

        

          Картинка с сайта: gb.ru
        
      
После импорта должно получиться примерно так:

        

          Картинка с сайта: gb.ru
        
      
После этого перезапускаем веб-сервер и возвращаемся на сайт. Видим окно выбора сертификата того пользователя, которого мы импортировали в браузер:

        

          Картинка с сайта: gb.ru
        
      

После выбора сертификата пользователя можно успешно зайти на сайт:

Картинка с сайта: gb.ru

В этой статье мы рассмотрели сборку простейшего ЦС. Его сертификат мы использовали для подтверждения других сертификатов, обеспечив таким образом доверие между всеми участниками. Но в собранной нами системе есть пара существенных недостатков:

• если пользователей будет больше одного, то мы столкнёмся с проблемами при учёте выдаваемых сертификатов;
• при настройке ЦС стоит грамотно выбирать параметры для используемых сертификатов, а для этого нужен свой конфигурационный файл.

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

Напоследок предлагаю ряд полезных материалов для изучения:

• Как получить тестовый сертификат криптопро за минуту
• Бесплатный SSL-сертификат Comodo
• Тестовый сертификат для ЭЦП

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

• What are Certificate Authorities & Trust Hierarchies?
• Public key infrastructure
• Инфраструктура открытых ключей
• PKI — Public Key Infrastructure
• Про PKI «на пальцах» за 10 минут
• How do you add a certificate authority (CA) to Ubuntu?
• How to install CA certificates in Ubuntu server
• Adding trusted root certificates to the server

Хотите в подробностях изучить работу центров сертификации и другие вопросы информационной безопасности? Тогда приглашаем вас на факультет GeekUniversity!

Who isn’t tired of certificate errors at internal devices that serve a WebUI but don’t have a trusted certificate? Let’s encrypt is probably not the best alternative as there is no public access to the server (it is still possible, but some configuration and “workarounds” are needed).

In this blog post, we’ll create our own simple Certificate Authority, which we’ll use to sign certificates we generate for our internal servers. We will also make sure that those are trusted certificates in our network. This post starts with the basics, so if you are familiar with certificates and CAs, how they work, the difference between a public key and a certificate, and why a certificate signing request is needed, skip the next section. If you are not that enlightened – let’s start with some theories:

How do CA’s and certificates, basically, work?

Let’s assume there is a server running a simple website. The traffic to the webserver should be encrypted (use https). This encryption is done via symmetric encryption, which means that there is one key to encrypt and decrypt the traffic. This key is generated when the connection is established and is exchanged between the client and server using asymmetric encryption (so there is a public/private key pair). Search for “SSL protocol” or “SSL handshake” for details. The basic idea is:

1. Client receives the public key of the server (public key is included in the certificate)
2. Client generates a symmetric key
3. Client encrypts the symmetric key with the public key of the server
4. Client sends the encrypted symmetric key to the server
5. Server decrypts the encrypted symmetric key (at this stage, client and server have the same key, so key exchange is done)
6. Client and server use the symmetric key to encrypt their communication

In step 1., the client receives a certificate containing the server’s public key and other information like the issuer, how long it is valid, which algorithms are used, what the certificate is about, etc. You can open a website and check the certificate details to see what it contains:

Картинка с сайта: arminreiter.com

Such certificates, as well as the public/private key pair, can be generated by everyone. You can generate a certificate for the domain example.com, even if you don’t own it. That’s why it’s important to know if you can trust a certificate or not. This trust is established through “Trusted Root Certificate Authorities”. Suppose I want to get a trusted certificate for arminreiter.com. In that case, I can generate a certificate and send a certificate signing request (CSR) for this certificate to a trusted certificate authority. They will check if I am the owner of arminreiter.com and will sign my certificate. Once I deploy the signed certificate, the website visitors (browser) know that it can be trusted because it is signed by a certificate authority they trust (the signature is validated). If it is not signed, users will get a warning (it could also be that a man-in-the-middle issued its own certificate to decrypt all the traffic – so be careful if you get this warning).

This works great for public websites, mainly because of https://letsencrypt.org/. However, it’s not that easy for internal servers as let’s encrypt can’t check the internal servers. (It is possible, but it requires some work).

For internal servers, one option is to create an own certificate authority (CA), configure the internal clients to trust this CA, and issue certificates that their own CA signs. The CA has its own key pair to sign the certificate requests.

Step-by-Step

Based on the information above, we know that we have to:

1. Create a private key for our own CA
2. Create a certificate for the CA
3. Add this certificate to the “Trusted Root Certificate Authorities” store of the clients so that it becomes trusted
4. Create a certificate for our webserver
5. Sign this certificate with our CA (which is trusted and therefore, also this new certificate becomes trusted)
6. Deploy the certificate

Using OpenSSL to create our CA

Step 1: Create a private key for the CA

Note: we will encrypt the key with AES because if anyone gets access to the key this person can create signed, trusted certificates. Encrypting the key adds some protection (use a 20+ password).

CANAME=MyOrg-RootCA

# optional
mkdir $CANAME
cd $CANAME

# generate aes encrypted private key
openssl genrsa -aes256 -out $CANAME.key 4096

Step 2: Create Certificate of the CA

# create certificate, 1826 days = 5 years
# the following will ask for common name, country, ...
openssl req -x509 -new -nodes -key $CANAME.key -sha256 -days 1826 -out $CANAME.crt

# ... or you provide common name, country etc. via:
openssl req -x509 -new -nodes -key $CANAME.key -sha256 -days 1826 -out $CANAME.crt -subj '/CN=MyOrg Root CA/C=AT/ST=Vienna/L=Vienna/O=MyOrg'

Step 3: Add the CA certificate to the trusted root certificates

For Windows: Open the .crt file and install it for all users to “Trusted Root Certificate Authorities” (verify it by running certmgr.msc)
if you use Intune: Go to Devices > Configuration Profiles > Create profile > Windows 10 and later, Templates, Trusted certificate > upload the .crt file

For Linux (Ubuntu):

sudo apt install -y ca-certificates
sudo cp $CANAME.crt /usr/local/share/ca-certificates
sudo update-ca-certificates

Linux (Fedora/CentOS):

sudo cp $CANAME.crt /etc/pki/ca-trust/source/anchors/$CANAME.crt
sudo update-ca-trust

is by sure also possible for Android, iOS, macOS, … => internet will help 😉

Step 4: Create a certificate for the webserver

MYCERT=myserver
openssl req -new -nodes -out $MYCERT.csr -newkey rsa:4096 -keyout $MYCERT.key -subj '/CN=My Firewall/C=AT/ST=Vienna/L=Vienna/O=MyOrg'

# create a v3 ext file for SAN properties
cat > $MYCERT.v3.ext << EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = myserver.local
DNS.2 = myserver1.local
IP.1 = 192.168.1.1
IP.2 = 192.168.2.1
EOF

Note: the v3.ext file contains the properties of the v3 extension of certificates. This includes especially the SAN (subject alternative names) which contains the information about DNS or IP, which the browser needs to trust the certificate (you somehow need to make sure, that mysite.local uses the certificate that was issued for mysite.local)

Step 5: Sign the certificate

openssl x509 -req -in $MYCERT.csr -CA $CANAME.crt -CAkey $CANAME.key -CAcreateserial -out $MYCERT.crt -days 730 -sha256 -extfile $MYCERT.v3.ext

Step 6: Deploy the certificate

no explanation here, as it depends on the server.

Source/Command Recap

All commands collected in one code block:

CANAME=MyOrg-RootCA

# optional, create a directory
mkdir $CANAME
cd $CANAME

# generate aes encrypted private key
openssl genrsa -aes256 -out $CANAME.key 4096

# create certificate, 1826 days = 5 years
openssl req -x509 -new -nodes -key $CANAME.key -sha256 -days 1826 -out $CANAME.crt -subj '/CN=My Root CA/C=AT/ST=Vienna/L=Vienna/O=MyOrganisation'

# create certificate for service
MYCERT=myserver.local
openssl req -new -nodes -out $MYCERT.csr -newkey rsa:4096 -keyout $MYCERT.key -subj '/CN=My Firewall/C=AT/ST=Vienna/L=Vienna/O=MyOrganisation'

# create a v3 ext file for SAN properties
cat > $MYCERT.v3.ext << EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = myserver.local
DNS.2 = myserver1.local
IP.1 = 192.168.1.1
IP.2 = 192.168.2.1
EOF

openssl x509 -req -in $MYCERT.csr -CA $CANAME.crt -CAkey $CANAME.key -CAcreateserial -out $MYCERT.crt -days 730 -sha256 -extfile $MYCERT.v3.ext

No, it is not. A “real” Root CA usually consists of a Root CA, which signs the certificates of Intermediate CAs, which then sign the certificates of websites (there could also be multiple Intermediate CAs => certificate chain). This increases the security a lot because the certificate of the Root CA is only needed in very special cases (new Intermediate CA added or revoked).
The CA we created is only a public/private key pair, so it also does not maintain and publish a Certificate Revocation List (CRL), usually done by CAs. A CRL lists all revoked certificates (e.g., because the private key got leaked/compromised). If a client receives a certificate, it will check if it is still valid by checking the CRL.
Besides the CRL, they should implement the Online Certificate Status Protocol (OCSP), an alternative to CRLs. It also allows the client to check if a certificate is still valid or revoked, but it has advantages over CRLs.

There are already many posts about this topic (see Further Information section), but some of them use outdated algorithms or do not contain exactly what I need.

Regarding the algorithms/usage:

• The private key of the Root CA should always be encrypted with a password. As stated above – if someone gets access to this key, this person is able to sign all certificates so that they become trusted.
• Triple-DES (3DES) is officially being retired (by NIST) and is therefore considered as unsecure. AES was created to replace 3DES (see e.g.: https://www.cryptomathic.com/news-events/blog/3des-is-officially-being-retired) and is still considered secure.
• RSA vs. Elliptic Curves: Elliptic Curves are basically preferred because of better security, higher efficiency, smaller keys and perfect forward secrecy – however, I used RSA 4096, because adoption is better (its basically available at all servers) and RSA is still unbroken.

Further Information

• OpenSSL Creating a Certificate Authority (CA): https://node-security.com/posts/openssl-creating-a-ca/
• Creating a browser trusted self-signed SSL certificate: https://medium.com/@tbusser/creating-a-browser-trusted-self-signed-ssl-certificate-2709ce43fd15
• Create Your Own SSL Certificate Authority for Local HTTPS Development: https://deliciousbrains.com/ssl-certificate-authority-for-local-https-development/
• How to Be Your Own Certificate Authority: https://www.wikihow.com/Be-Your-Own-Certificate-Authority
• How to Create Trusted Self-Signed SSL Certificates and Local Domains for Testing: https://betterprogramming.pub/trusted-self-signed-certificate-and-local-domains-for-testing-7c6e6e3f9548
• OpenSSL Certificate Authority: https://jamielinux.com/docs/openssl-certificate-authority/introduction.html