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

Описание секции sslinsecurerenegotiation в apache 2.2

Теперь, давайте я расскажу, для чего нам нужна секция SSLInsecureRenegotiation, и стоит ли вообще Вам ее использовать.

Данная секция нужна для включения поддержки старых протоколов SSL и TLS, так как все новые Web сервера и браузеры работают на более новых версиях. Потому что была обнаружена уязвимость, которая позволяла хакеру, вклинится в данное соединение.

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

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

А если у Вас и в этих браузерах не работало, то посмотрите, какую версию Вы используете. Точно не знаю, но по-моему, все версии FireFox до 3.5 работают на старых протоколах. Это относится и к Internet Explorer, версии до 8 не будут работать с клиентскими сертификатами, если Вы используете последние версии Apache и SSL.

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

Поэтому в данном случае можно прописать данный параметр, выставив его в ON и одновременно написать своим пользователям, какие требования к ОС и приложениям будут введены с какого-то времени, для того чтобы они обновились, или если у Вас корпоративный ресурс, то попросить админов сделать это.

Ssl virtual host на apache 2.2 mod_ssl и самоподписанные сертификаты

Авторизация по клиентским сертификатам в apache 2.2 не работает

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

Например, в браузере FireFox у Вас появилась следующая ошибка:

 
   ssl_error_handshake_failure_alert

Это свидетельствует о том, что Вы не прошли авторизацию по сертификату. Изначально причин может быть много, например:

• Не установлен сертификат в браузер;
• Сертификат сгенерирован неправильно;
• Неправильно настроен Apache;
• Или, как раз на сервере используется новые протоколы безопасности, а на клиенте нет.

Поэтому, если Вы уверенны, что первые три пункта Вы все сделали правильно, то остается только один вариант, о котором мы сегодня и говорим.

Все то же самое относится и к Internet Explorer, только там будет выходить другая, более общая ошибка, типа:

«Internet Explorer не может отобразить эту веб-страницу.»

Примечание! В некоторых случаях помогает просто отключить поддержку протокола TLS 1.0 в браузере IE при условии, что все обновления ОС установлены. «Сервис -> Свойства обозревателя ->Дополнительно -> убрать галочку TLS 1.0».

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

Итак, нам удалось настроить и протестировать 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. Примеры значений сертификата.

Изменение файла виртуального хоста apache ssl по умолчанию

Теперь изменим /etc/apache2/sites-available/sl.conf, используемый по умолчанию файл виртуального хоста Apache SSL. Если вы используете другой файл серверных блоков, используйте имя этого файла в приведенных ниже командах.

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

Теперь откройте файл виртуального хоста SSL для внесения изменений:

С удалением большинства комментариев содержание файла виртуального хоста по умолчанию должно выглядеть примерно так:

/etc/apache2/sites-available/default-ssl.conf

Как установить ssl сертификат на apache? |

Настройка ssl сертификата для apache

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

Конфигурационный  файл(ы) в RedHat’s можно создать:

Онлайн курс “sre практики и инструменты”

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с

онлайн-курсом “SRE практики и инструменты”

в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и Linux. Обучение длится 3 месяц, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

На курсе вы узнаете как:

• Внедрить SRE практики в своей организации
• Управлять надежностью, доступностью и эффективностью сервисов
• Управлять изменениями
• Осуществлять мониторинг
• Реагировать на инциденты и производительность
• Работать со следующим технологическим стеком: Linux, AWS, GCP, Kubernetes, Ansible, Terraform, Prometheus, Go, Python.

Проверьте себя на вступительном тесте и смотрите подробнее программу по

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

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

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

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

Помогла статья? подписывайся на telegram канал автора

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

Предварительные требования

Для начала у вас должен быть пользователь без прав root с привилегиями sudo. Чтобы создать такую учетную запись пользователя, следуйте указаниям руководства «Начальная настройка сервера с Ubuntu 18.04».

Также вам потребуется установить веб-сервер Apache. Если вы хотите установить на сервере полный комплект LAMP (Linux, Apache, MySQL, PHP), следуйте указаниям обучающего модуля «Установка LAMP в Ubuntu 18.04». Если вы хотите просто установить веб-сервер Apache, пропустите шаги, относящиеся к установке PHP и MySQL.

Когда предварительные требования будут выполнены, переходите к приведенным ниже шагам.

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

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

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

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

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

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

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

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

Создание сниппета конфигурации apache с надежными настройками шифрования

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

Создайте новый сниппет в каталоге /etc/apache2/conf-available. Мы назовем файл ssl-params.conf, чтобы сделать его назначение очевидным:

Для безопасной настройки Apache SSL мы используем рекомендации Реми ван Эльста на сайте Cipherli.st. Этот сайт создан для предоставления удобных настроек шифрования для популярного программного обеспечения.

Рекомендованные настройки на вышеуказанном сайте обеспечивают высокий уровень безопасности. Иногда это достигается за счет совместимости клиентских систем. Если вам требуется поддержка старых версий клиентов, вы можете использовать альтернативный список, нажав на странице ссылку «Да, мне нужны настройки шифрования для устаревшего / старого программного обеспечения». Этот список можно заменить для копируемых ниже элементов.

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

Для наших целей мы скопируем предоставленные настройки полностью. Мы внесем только одно небольшое изменение. Мы отключим заголовок Strict-Transport-Security (HSTS).

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

Способ 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

Установка mod_ssl в apache

В качестве сервера у нас выступает apache на CentOS, хотя это не принципиально, настройка на других linux дистрибутивах будет идентичной. Рабочим web сервером является apache. Использовать ssl протокол в apache мы будем с помощью мода mod_ssl. Первым делом проверим, установлен ли он:

# rpm -qa | grep mod_ssl

Если нет, то устанавливаем:

# yum -y install mod_ssl

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

Теперь можно продолжить установку закрытого ключа веб-сервера (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/ 

Шаг 2 — настройка apache для использования ssl

Мы создали файлы ключа и сертификата в каталоге /etc/ssl. Теперь нам просто нужно изменить конфигурацию Apache, чтобы воспользоваться их преимуществами.

Внесем несколько небольших изменений в нашу конфигурацию:

1. Создадим сниппет конфигурации, чтобы задать надежные параметры SSL по умолчанию.
2. Мы изменим входящий в комплект файл виртуального хоста SSL Apache, чтобы он указывал на сгенерированные нами сертификаты SSL.
3. (Рекомендуется) Мы изменим незашифрованный файл виртуального хоста, чтобы он автоматически перенаправлял запросы на шифрованный виртуальный хост.

После завершения настройки мы получим защищенную конфигурацию SSL.

Шаг 3 — настройка брандмауэра

Если у вас включен брандмаэр ufw в соответствии с предварительными требованиями, вам может потребоваться изменить настройки для поддержки трафика SSL . К счастью, Apache регистрирует несколько профилей ufw после установки.

Мы можем просмотреть доступные профили с помощью следующей команды:

Список должен выглядеть примерно так:

Output
Available applications:
  Apache
  Apache Full
  Apache Secure
  OpenSSH

Вы можете просмотреть текущие настройки с помощью следующей команды:

Шаг 4 — активация изменений в apache

Мы внесли изменения и настроили брандмауэр, и теперь можем включить в Apache модули SSL и заголовков, активировать наш виртуальный хост SSL и перезапустить Apache.

Мы можем активровать mod_ssl, модуль Apache SSL, и модуль mod_headers, необходимый для некоторых настроек нашего сниппета SSL, с помощью команды a2enmod:

Теперь мы можем активировать виртуальный хост SSL с помощью команды a2ensite:

Также нам нужно будет активировать файл ssl-params.conf для считывания заданных значений:

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

Если проверка будет успешно пройдена, мы получим результат, выглядящий примерно так:

Output
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
Syntax OK

Первая строка — это сообщение о том, что директива ServerName не задана глобально. Если вы хотите избавиться от этого сообщения, вы можете задать для ServerName доменное имя вашего сервера или IP-адрес в каталоге /etc/apache2/apache2.conf. Это необязательно, потому что данное сообщение не наносит никакого вреда.

Если в результатах есть сообщение Syntax OK, в вашей конфигурации нет синтаксических ошибок. Мы можем безопасно перезапустить Apache для внесения изменений:

Шаг 6 – переключение на постоянное перенаправление

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

Откройте файл конфигурации серверного блока еще раз:

Найдите добавленную нами строку Redirect. Добавьте в эту строку атрибут permanent, который изменяет тип перенаправления с временного перенаправления 302 на постоянное перенаправление 301:

/etc/apache2/sites-available/000-default.conf

Заключение

Вы настроили сервер Apache для использования защищенного шифрования клиентских соединений. Это обеспечит безопасное обслуживание запросов и не даст третьим сторонам возможности считывать ваш трафик.

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

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