Apache 2 с SSL/TLS: Шаг за Шагом, Часть 2

 Автор Artur Maj

В первой статье этого цикла мы рассказали как правильно устанавливать настраивать и устранять неисправности Apache 2.0 с поддержкой SSL/TLS. Во второй части мы обсудим рекомендуемые настройки mod_ssl, нацеленные на получение максимальной безопасности и оптимальной производительности. Кроме того, читатель узнает, как создать локальный Certification Authority и SSL-сертификат, используя OpenSSL библиотеку с открытым кодом.

Рекомендуемые настройки mod_ssl

В Apache 2.0.52 существует более 30 директив, используемых для настройки mod_ssl. Подробное описание их всех можно найти в Apache's mod_ssl documentation. В этом разделе рассмотрим только рекомендуемые настройки, которые влияют на безопасность или производительность SSL/TLS соединений.

Листинг этих настроек показан в Таблице 1.

Table 1. Рекомендуемые настройки mod_ssl.

Вот наш пример настоек в httpd.conf, следую рекомендациям выше:

SSLEngine on

SSLOptions +StrictRequire

<Directory />

    SSLRequireSSL

</Directory>

SSLProtocol -all +TLSv1 +SSLv3

# Support only for strong cryptography

SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM

# Support for strong and export cryptography

# SSLCipherSuite HIGH:MEDIUM:EXP:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM:+EXP

SSLRandomSeed startup file:/dev/urandom 1024

SSLRandomSeed connect file:/dev/urandom 1024

SSLSessionCache shm:/usr/local/apache2/logs/ssl_cache_shm

SSLSessionCacheTimeout 600

SSLVerify none

SSLProxyEngine off

Как дополнение к вышеупомянутым директивам mod_ssl, существуют еще две очень важные директивы от других модулей Apache (mod_log_config и mod_set_envif), которые нужно настроить, как показано в Таблице 2.

  CustomLog logs/ssl_request_log \ 

  "%t %h %{HTTPS}x %{SSL_PROTOCOL}x %{SSL_CIPHER}x 

  %{SSL_CIPHER_USEKEYSIZE}x %{SSL_CLIENT_VERIFY}x 

  SetEnvIf User-Agent ".*MSIE.*" \ 

    nokeepalive ssl-unclean-shutdown \

    downgrade-1.0 force-response-1.0

Table 2. Рекомендуемы настройки mod_log и mod_set_envif.

Пример конфигурационного файла (httpd.conf), представленного в предыдущей статье уже включает настройки, приведенные выше.

Аутентификация веб сервера

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

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

• Открытый ключ веб-сервера
• Даты подлинности (начала и истечения)
• Поддерживаемые алгоритмы шифрования
• Отличительное имя (the distinguish name DN), которое должно содержать полностью определенное доменное имя веб-сервера, называемое общим именем (Common Name CN). Опционально DN может содержать и некоторые другие атрибуты, например, страну (Country C), штат (State S), Расположение (Location L), название организации (the Organization's name O), название службы организации (the Organization Unit's name OU), и др.
• Серийный номер сертификата
• Атрибуты X.509v3, которые будут сообщать веб-браузерам о типе и применении
• URI CRL (если есть)
• URI политики сертификата X.509v3 (если есть)
• Имя и подпись доверенного источника сертификатов (Certification Authority CA)

Стоит отметить, что атрибут общее имя (Common Name CN) должен иметь значение, равное доменному имени сервера (Fully Qualified Domain Name FQDN). Иначе браузерам не удастся определить принадлежность сертификата веб-серверу, на котором присутствует наш сертификат.

Пример сертификата веб-сервера (текстовая репродукция):

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number: 1 (0x1)

        Signature Algorithm: sha1WithRSAEncryption

        Issuer: O=Seccure, OU=Seccure Root CA

        Validity

            Not Before: Nov 28 01:00:20 2004 GMT

            Not After : Nov 28 01:00:20 2005 GMT

        Subject: O=Seccure, OU=Seccure Labs, CN=www.seccure.lab

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

            RSA Public Key: (1024 bit)

                Modulus (1024 bit):

                    00:c1:19:c7:38:f4:89:91:27:a2:1b:1d:b6:8d:91:

                    48:63:0e:3d:0d:2e:f8:65:45:56:db:98:4d:11:21:

                    01:ac:81:8e:3f:64:4a:8a:3f:21:15:ca:49:6e:64:

                    5c:5d:a2:ab:5a:48:cb:2a:9f:0c:02:b9:ff:52:f6:

                    d9:39:6d:a3:4a:94:41:f9:e9:ab:f0:42:fb:68:9a:

                    4b:53:41:e7:4f:b0:2b:02:d7:92:a2:2b:02:a2:f9:

                    f1:2d:68:fa:50:01:2f:49:c1:28:2f:a8:c6:6d:6d:

                    ab:1d:b9:bd:c9:80:63:f1:d6:22:19:de:2d:4a:43:

                    50:76:79:7e:a5:5a:75:af:19

                Exponent: 65537 (0x10001)

        X509v3 extensions:

            X509v3 Basic Constraints:

                CA:FALSE

            Netscape Cert Type:

                SSL Server

            X509v3 Key Usage:

                Digital Signature, Key Encipherment

            X509v3 Extended Key Usage:

                TLS Web Server Authentication, Netscape Server Gated Crypto, 

                                                             Microsoft Server Gated Crypto

            Netscape Comment:

                OpenSSL Certificate for SSL Web Server

    Signature Algorithm: sha1WithRSAEncryption

        45:30:9d:04:0e:b7:86:9e:61:a1:b0:68:2b:44:93:1c:57:2a:

        99:42:bb:16:b1:ab:f5:c0:d2:33:12:c8:d3:1d:2b:bb:6b:9a:

        4c:c7:53:bc:e4:88:ef:1e:c3:37:ed:53:2c:15:cf:b8:90:df:

        df:4b:34:b8:db:cc:23:77:46:06:72:9d:43:60:a8:a2:ed:0a:

        bb:1a:a4:e8:4e:ba:66:93:63:74:87:fd:43:48:b6:93:a2:e3:

        3d:da:1b:64:46:35:88:b4:4b:22:e6:3c:84:70:5d:88:dd:64:

        c2:51:c2:d6:59:80:87:bc:bd:7f:e3:c1:45:7e:c0:5f:9c:ca:

        e1:a1

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

Table 3. Примеры значений сертификата.

Парольная фраза dilemma

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

1. Необходимо будет вводить парольную фразу после каждой перезагрузки сервера, что может раздражать, если систему нужно часто перезагружать (например, при обновлении ядра, перебоях с питанием, смене конфигурации и т.п.)
2. Если злоумышленнику удастся получить закрытый ключ на веб-сервере, это будет означать, что веб-сервер уже компрометирован и взломщик получит привилегии root’a. В этом случае хакер сможет узнать и парольную фразу, установив кей-логгер и перезагрузив систему, тем самым он всё равно заставит системного администратора ввести парольную фразу. Также злоумышленник может просмотреть память Apache и найти закрыйтый ключ веб-сервера, хранимого в дампе в открытом тексте. Хотя осуществить это сложно, но для тех, кто имеет опыт во взломе систем семейства Unix, большой проблемы это не вызовет (самый простой способ - использовать утилиту pcat из The Coroner's Toolkit).

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

Создаем сертификат веб-сервера

Теперь мы можем создать сертификат нашего веб-сервера. Вообще, существует три типа сертификатов, которые мы можем использовать:

1. Самоподписанный сертификат.
2. Сертификат, подписанный доверенным CA (наиболее рекомендуемый).
3. Сертификат, подписанный локальным CA.

Следующие разделы подробно описывают способы создания этих сертификатов. Конечный результат любого способа будет всего в двух файлах:

• server.key – закрытый ключ веб-сервера
• server.crt – зашифрованный PEM сертификат, содержащий открыйтый ключ сервера

Способ 1: Самоподписанный сертификат (только для тестирования)

Этот способ стоит использовать только для продолжения нашего тестирования, или для использования в малых, закрытых условиях (малые корпоративные сети). Чтобы веб-браузеры могли аутентифицировать веб-сервер, самоподписанные сертификаты должны быть инсталлированы в каждый веб-браузер. Это может быть довольно таки неудобно.

Закрытый/открытый ключ и самоподписанный РЕМ-зашифрованный сертификат создаются следующим образом:

openssl req \ 
-new \ 
-x509 \ 
-days 365 \ 
-sha1 \ 
-newkey rsa:1024 \ 
-nodes \ 
-keyout server.key \ 
-out server.crt \ 
-subj '/O=Seccure/OU=Seccure Labs/CN=www.seccure.lab'

При помощи этих команд выполняются следующие действия: создание нового (-new) сертификата (-x509), который будет действителен в течение года (-days 365) и будет подписан с использованием алгоритма SHA1 (-sha1). Закрытый ключ RSA будет иметь длину 1024 бит (-newkey rsa:1024), и не будет защищен парольной фразой (-nodes). Сертификат и закрытый/открытый ключи будут созданы в файлах "server.crt" и "server.key" (-out server.crt -keyout server.key). Параметр "-subj" говорит о том, что название компании "Seccure" (O=Seccure), название службы "Seccure Labs", и полностью определенное доменное имя "www.seccure.lab".

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

Рисунок 1. Установка самоподписанного сертификата на машину клиента.

Способ 2: Сертификат, подписанный доверенным CA (рекомендуется)

Создание запроса на сертификат и подписка его доверенным CA (таким как Thawte, RSA и др.) наиболее рекомендуемое дальнейшее действие, если вы хотите открыть публичный доступ к вашему сайту из Интернет. При использовании этого метода отпадает необходимость в установке сертификатов в каждый веб-браузер, ведь большинство из них уже имеют в установке несколько сертификатов от доверенных CA.

Не забывайте, что каждый СА имеет разные ограничение на атрибут DN, поэтому читателю стоит заранее ознакомиться с ними. Рекомендуется также выбирать такие сертификаты, которые установлены в большинстве веб браузеров (Thawte, Verisign и некоторые другие). Иначе, у веб-браузера пользователя возникнут проблемы с аутентификацией веб-сервера.

Процесс получения подписанного сертификата от доверенного СА состоит из следующих шагов:

1. Первым делом, следует создать пару закрытого/открытого ключа (server.key) и запрос сертификата (request.pem), как показано ниже:

openssl req \ 
-new \ 
-sha1 \ 
-newkey rsa:1024 \ 
-nodes \ 
-keyout server.key \ 
-out request.pem \ 
-subj '/O=Seccure/OU=Seccure Labs/CN=www.seccure.lab'

2.  Теперь мы должны послать запрос на получение сертификата (request.pem) в СА и дождаться, пока он будет подписан и отослан обратно в виде сертификата.

3.  После получения сертификата от доверенного СА мы должны удостовериться в том, что он закодирован в формате PEM, а не TXT или DER. Если же полученный сертификат не соответствует формату РЕМ, то мы должны конвертировать его, в каком бы формате он не пришел.

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

• PEM, Base64 кодировка формата X.509 (*.crt, *.pem, *.cer)

-----BEGIN CERTIFICATE-----
MIICdzCCAeCgAwIBAgIBATANBgkqhkiG9w0BAQUFADAsMRAwDgYDVQQKEwdTZWNj
dXJlMRgwFgYDVQQLEw9TZWNjdXJlIFJvb3QgQ0EwHhcNMDQxMTI4MDEwMDIwWhcN
...
ou0Kuxqk6E66ZpNjdIf9Q0i2k6LjPdobZEY1iLRLIuY8hHBdiN1kwlHC1lmAh7y9
f+PBRX7AX5zK4aE=
-----END CERTIFICATE-----

• TXT + PEM format (*.crt, *.cer, *.pem, *.txt)

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: O=Seccure, OU=Seccure Root CA
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:c1:19:c7:38:f4:89:91:27:a2:1b:1d:b6:8d:91:
...
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
...
-----BEGIN CERTIFICATE-----
MIICdzCCAeCgAwIBAgIBATANBgkqhkiG9w0BAQUFADAsMRAwDgYDVQQKEwdTZWNj
dXJlMRgwFgYDVQQLEw9TZWNjdXJlIFJvb3QgQ0EwHhcNMDQxMTI4MDEwMDIwWhcN
...
ou0Kuxqk6E66ZpNjdIf9Q0i2k6LjPdobZEY1iLRLIuY8hHBdiN1kwlHC1lmAh7y9
f+PBRX7AX5zK4aE=
-----END CERTIFICATE-----

Команда для конвертирования формата TXT + PEM в РЕМ:

openssl x509 -in signed_cert.pem -out server.crt

• DER, двоичная кодировка X.509 (*.der, *.crt, *.cer)

[Нетекстовое, двоичное представление]

Команда для преобразования формата DER в РЕМ:

openssl x509 -in signed_cert.der -inform DER -out server.crt

4. Верификация и тестирование сертификата

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

openssl verify -CAfile /path/to/trusted_ca.crt -purpose sslserver server.crt

Кроме того, было бы неплохо убедиться в том, что наш сертификат соответствует ранее созданному закрытому ключу (результаты выполнения обеих команд должны быть одинаковыми):

openssl x509 -noout -modulus -in server.crt | openssl sha1
openssl rsa -noout -modulus -in server.key | openssl sha1

Способ 3: Сертификат, подписанный локальным CA

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

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

Примечание: Локальный СА должен быть создан на отдельном сервере, который не имеет соединения с сетью. Операционная система должна давать доступ только авторизованному персоналу, а сама машина должна быть под охраной. Закрытый СА ключ – самый важный элемент всей системы PKI – если он будет компрометирован, то все другие сертификаты, подписанные этим СА также будут компрометированы!

Для установки среды мы будет использовать библиотеку OpenSSL. Понятно, что если у нас уже есть локальный СА, мы можем пропустить этот раздел и продолжить создание запроса на сертификат для веб-сервера.

1. Подготовим структуру каталога для нового СА (среда переменной $SSLDIR должна быть добавлена в соответствующие скрипты автозагрузки, такие как /etc/profile или /etc/rc.local:

export SSLDIR=$HOME/ca 
mkdir $SSLDIR 
mkdir $SSLDIR/certs 
mkdir $SSLDIR/crl 
mkdir $SSLDIR/newcerts 
mkdir $SSLDIR/private 
mkdir $SSLDIR/requests 
touch $SSLDIR/index.txt 
echo "01" > $SSLDIR/serial 
chmod 700 $SSLDIR

2. Создаем основной файл настроек OpenSSL - $SSLDIR/openssl.cnf, со следующим содержанием (оптимизировано для использования с SSL веб-серверами):

# =================================================
# OpenSSL configuration file
# =================================================
RANDFILE         = $ENV::SSLDIR/.rnd
[ ca ]
default_ca       = CA_default
[ CA_default ]
dir              = $ENV::SSLDIR
certs            = $dir/certs
new_certs_dir    = $dir/newcerts
crl_dir          = $dir/crl
database         = $dir/index.txt
private_key      = $dir/private/ca.key
certificate      = $dir/ca.crt
serial           = $dir/serial
crl              = $dir/crl.pem
RANDFILE         = $dir/private/.rand
default_days     = 365
default_crl_days = 30
default_md       = sha1
preserve         = no
policy           = policy_anything
name_opt         = ca_default
cert_opt         = ca_default
[ policy_anything ]
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional
[ req ]
default_bits            = 1024
default_md              = sha1
default_keyfile         = privkey.pem
distinguished_name      = req_distinguished_name
x509_extensions         = v3_ca
string_mask             = nombstr
[ req_distinguished_name ]
countryName             = Country Name (2 letter code)
countryName_min         = 2
countryName_max         = 2
stateOrProvinceName     = State or Province Name (full name)
localityName            = Locality Name (eg, city)
0.organizationName      = Organization Name (eg, company)
organizationalUnitName  = Organizational Unit Name (eg, section)
commonName              = Common Name (eg, YOUR name)
commonName_max          = 64
emailAddress            = Email Address
emailAddress_max        = 64
[ usr_cert ]
basicConstraints        = CA:FALSE
# nsCaRevocationUrl       = https://url-to-exposed-clr-list/crl.pem
[ ssl_server ]
basicConstraints        = CA:FALSE
nsCertType              = server
keyUsage                = digitalSignature, keyEncipherment
extendedKeyUsage        = serverAuth, nsSGC, msSGC
nsComment               = "OpenSSL Certificate for SSL Web Server"
[ ssl_client ]
basicConstraints        = CA:FALSE
nsCertType              = client
keyUsage                = digitalSignature, keyEncipherment
extendedKeyUsage        = clientAuth
nsComment               = "OpenSSL Certificate for SSL Client"
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage         = nonRepudiation, digitalSignature, keyEncipherment
[ v3_ca ]
basicConstraints        = critical, CA:true, pathlen:0
nsCertType              = sslCA
keyUsage                = cRLSign, keyCertSign
extendedKeyUsage        = serverAuth, clientAuth
nsComment               = "OpenSSL CA Certificate"
[ crl_ext ]
basicConstraints        = CA:FALSE
keyUsage                = digitalSignature, keyEncipherment
nsComment               = "OpenSSL generated CRL"

openssl req \ 
-config $SSLDIR/openssl.cnf \ 
-new \ 
-x509 \ 
-days 3652 \ 
-sha1 \ 
-newkey rsa:1024 \ 
-keyout $SSLDIR/private/ca.key \ 
-out $SSLDIR/ca.crt \ 
-subj '/O=Seccure/OU=Seccure Root CA'

Для закрытого СА ключа следует придумать парольную фразу, которую трудно подобрать и она должна быть нормальной большее количество времени, чем обычные сертификаты (обычно от 10 до 30 лет или больше).

Сертификат СА "ca.crt" следует выложить в открытый доступ на веб-страницах интрасети и установить в каждый веб-браузер, которому он может понадобиться. Ниже показан пример установленного в Internet Explorer сертификата.

Рисунок 2. Пример корневого CA сертификата, установленного в Internet Explorer.

Теперь мы можем использовать наш локальный СА для подписания/аннулирования сертификатов. Для создания сертификата веб-сервера нужно следовать следующим шагам:

1. Создаем пару закрытый/открытый ключ веб-сервера (server.key), и запрос на сертификат (request.pem). На веб-сервере нужно выполнить следующие команды:

openssl req \ 
-new \ 
-sha1 \ 
-newkey rsa:1024 \ 
-nodes \ 
-keyout server.key \ 
-out request.pem \ 
-subj '/O=Seccure/OU=Seccure Labs/CN=www.seccure.lab'

2. Копируем этот запрос (request.pem) в директорию $SSLDIR/requests на хост CA  (с использованием переносимого носителя, например USB драйва).
3. Подпишем запрос на сертификат (команды выполнять только на хосте СА):

openssl ca \ 
-config $SSLDIR/openssl.cnf \ 
-policy policy_anything \ 
-extensions ssl_server \ 
-out $SSLDIR/requests/signed.pem \ 
-infiles $SSLDIR/requests/request.pem

4.      Результатом этих команд будет подписанный сертификат (signed.pem) , который будет находится в директории $SSLDIR/newcerts, и в файле $SSLDIR/signed.pem. Он состоит сразу из TXT и PEM представлении сертификата. Так как Apache ожидает усеченный вариант в формате PEM , мы конвертируем его:

openssl x509 \ 
-in $SSLDIR/requests/signed.pem \ 
-out $SSLDIR/requests/server.crt

5. Скопируйте подписанный, в формате PEM сертификат (server.crt) обратно на машину, которая является веб-сервером.

Теперь сертификат готов к использованию.

Для местных СА в случае компрометации сертификата строго рекомендуется аннулировать сертификат и информировать пользователей о том, что сертификат больше не действителен. Для аннулирования  сертификата мы должны отыскать его серийный номер в файле $SSLDIR/index.txt. Далее выполняем следующие команды:

openssl ca \ 
-config $SSLDIR/openssl.cnf \ 
-revoke $SSLDIR/newcerts/.pem 

Для создания CRL (Certificate Revocation List – Список Аннулированных Сертификатов) файла, делаем следующее:

openssl ca -config $SSLDIR/openssl.cnf -gencrl -crlexts crl_ext -md sha1 -out $SSLDIR/crl.pem

Этот файл должен быть опубликован на сайте СА и/или предоставлен пользователям иным способом. В процессе распространения CRL’ов также рекомендуется использовать Online Certificate Status Protocol (OCSP). Более подробную информацию можно найти в RFC 2560.

Заметьте, что некоторые браузеры (включая Firefox) принимают CRL’ы только в формате DER, поэтому для установки сертификатов в эти браузеры потребуется конвертировать файл crl.pem:

openssl crl \ 
-in $SSLDIR/crl.pem \ 
-out $SSLDIR/revoke_certs.crl \ 
-outform DER

Кроме того, чтобы браузер проверял - не аннулирован ли сертификат веб-сервера, нужно установить опцию "Check for server certificate revocation" (Проверять аннулирование сертификатов серверов). Пример для MS Internet Explorer:

Рисунок 3. Настройка Internet Explorer на проверку аннулирования сертификатов.

Рисунок 4. Реакция Internet Explorer на аннулированный сертификат.

Установка сертификата

Теперь можно продолжить установку закрытого ключа веб-сервера (server.key) и самого сертификата (server.crt) в среду Apache:

install -m 600 -o root -g sys server.key /usr/local/apache2/conf/ssl.key/ 
install -m 644 -o root -g sys server.crt /usr/local/apache2/conf/ssl.crt/ 

Следует проверить, что директивы в конфигурации Apache ссылаются именно на файлы, указанные выше (в httpd.conf):

SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt 
SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server.key

Наконец, перезапускаем Apache и изменения вступают в силу:

SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt 
SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server.key

Проверим, работает ли SSL веб-сайт и могут ли браузеры аутентифицировать веб-сервер. Теперь не должно появиться никаких сообщений:

Рисунок 5. Безопасное соединение с действующим законным сертификатом.

Заключение второй части 

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