Настройка https на apache windows: Настройка Apache для работы баз 1С:Предприятие через HTTPS (SSL)

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

ВАЖНО: из соображений безопасности никогда не публикуйте и не разглашайте закрытый ключ SSL вашего сервера на общедоступном форуме.

После получения сертификата и файлов ключей сертификата вам потребуется обновить сервер, чтобы использовать их.

Подход A: Установка Bitnami с использованием системных пакетов

Чтобы активировать поддержку SSL, выполните следующие действия:

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

  Переменная	Значение
  URL текущего приложения	https://[пользовательский домен]/
  	Пример: https://мой-домен.com/ или https://мой-домен.com/имя_приложения
  Файл виртуального хоста приложения	installdir/apache2/conf/vhosts/APPNAME-https-vhost.conf
  Файл конфигурации Apache	каталог установки/apache2/conf/bitnami/bitnami. conf
  Файл сертификата	каталог установки/apache2/conf/bitnami/certs/server.crt
  Ключевой файл сертификата	installdir/apache2/conf/bitnami/certs/server.key

• Скопируйте сертификат SSL и файл ключа сертификата в указанные места.

  ПРИМЕЧАНИЕ. Если вы используете разные имена для файлов сертификатов и ключей, вам следует перенастроить директивы SSLCertificateFile и SSLCertificateKeyFile в соответствующем файле конфигурации Apache, чтобы они отражали правильные имена файлов.

• Если ваш центр сертификации также предоставил вам пакет центра сертификации (ЦС) в кодировке PEM, вы должны скопировать его в правильное место в предыдущей таблице.

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

  Переменная	Значение
  Файл виртуального хоста приложения	installdir/apache2/conf/vhosts/APPNAME-https-vhost.conf
  Файл конфигурации Apache	каталог установки/apache2/conf/bitnami/bitnami.conf
  Директива, включающая	SSLCACertificateFile «installdir/apache2/conf/bitnami/certs/server-ca.crt»

  ПРИМЕЧАНИЕ. Если вы используете другое имя для пакета сертификатов ЦС, вам следует перенастроить SSLCertificateChainFile или SSLCACertificateFile в соответствующем файле конфигурации Apache, чтобы отразить правильное имя файла.

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

   $ sudo chown root: root installdir/apache2/conf/bitnami/certs/server*
    $ sudo chmod 600 installdir/apache2/conf/bitnami/certs/server*
   

• Откройте порт 443 в брандмауэре сервера. Дополнительные сведения см. в разделе часто задаваемых вопросов для Windows, Linux и macOS.

• Перезапустите сервер Apache.

Теперь вы сможете получить доступ к своему приложению, используя URL-адрес HTTPS. В случае ошибок запуска сервера проверьте сертификат SSL и ключ

Подход B: Автономные установки Bitnami

Чтобы активировать поддержку SSL, выполните следующие действия:

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

  Переменная	Значение
  URL текущего приложения	https://[пользовательский домен]/
  	Пример: https://мой-домен.com/ или https://мой-домен.com/имя_приложения
  Файл конфигурации Apache	каталог установки/apache2/conf/bitnami/bitnami.conf
  Файл сертификата	каталог установки/apache2/conf/server. crt
  Ключевой файл сертификата	installdir/apache2/conf/server.key

• Скопируйте сертификат SSL и файл ключа сертификата в указанные места.

  ПРИМЕЧАНИЕ. Если вы используете разные имена для файлов сертификатов и ключей, вам следует перенастроить директивы SSLCertificateFile и SSLCertificateKeyFile в соответствующем файле конфигурации Apache, чтобы они отражали правильные имена файлов.

• Если ваш центр сертификации также предоставил вам пакет центра сертификации (ЦС) в кодировке PEM, вы должны скопировать его в правильное место в предыдущей таблице. Затем измените файл конфигурации Apache, включив следующую строку под директивой SSLCertificateKeyFile . Выберите правильную директиву в зависимости от вашего сценария и версии Apache:

  .

  Переменная	Значение
  Файл конфигурации Apache	каталог установки/apache2/conf/bitnami/bitnami. conf
  Директива для включения (Apache v2.4.8+)	SSLCACertificateFile «installdir/apache2/conf/server-ca.crt»
  Директива для включения (Apache < v2.4.8)	SSLCertificateChainFile «installdir/apache2/conf/server-ca.crt»

  ПРИМЕЧАНИЕ. Если вы используете другое имя для пакета сертификатов ЦС, вам следует перенастроить SSLCertificateChainFile или SSLCACertificateFile в соответствующем файле конфигурации Apache, чтобы отразить правильное имя файла.

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

   $ sudo chown root: root installdir/apache2/conf/server*
    $ sudo chmod 600 installdir/apache2/conf/сервер*
   

• Откройте порт 443 в брандмауэре сервера. Дополнительные сведения см. в разделе часто задаваемых вопросов для Windows, Linux и macOS.

• Перезапустите сервер Apache.

Теперь вы сможете получить доступ к своему приложению, используя URL-адрес HTTPS. В случае ошибок при запуске сервера проверьте SSL-сертификат и ключ.

Ознакомьтесь со следующими руководствами, если хотите узнать больше о настройке HTTPS.

SSL/TLS Strong Encryption: How-To — Apache HTTP Server Version 2.4

Apache HTTP Server Version 2.4

Доступные языки:  en  | фр 

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

• Пример базовой конфигурации
• Наборы шифров и усиление безопасности
• Сшивание OCSP
• Аутентификация клиента и контроль доступа
• Регистрация

См.

• Комментарии

Ваша конфигурация SSL должна содержать как минимум следующие директивы.

 LoadModule модули ssl_module/mod_ssl.so
Слушай 443
<Виртуальный хост *:443>
    Имя сервера www.example.com
    SSLEngine включен
    SSLCertificateFile "/path/to/www.example.com.cert"
    SSLCertificateKeyFile "/path/to/www.example.com.key"
 

• Как создать сервер SSL, который принимает только надежное шифрование?
• Как я могу создать сервер SSL, который принимает все типы шифров в целом, но требуется надежный шифр для доступа к определенному URL-адресу?

Как создать сервер SSL, который принимает надежное шифрование Только?

Следующее включает только самые стойкие шифры:

 SSLCipherSuite HIGH:!aNULL:!MD5 

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

 SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:!aNULL:!MD5
SSLHonorCipherOrder на 

Как мне создать сервер SSL, который принимает все типы шифров в целом, но требует надежных шифров для доступа к конкретному URL?

Очевидно, общесерверный SSLCipherSuite , который ограничивает шифры к сильным вариантам, здесь не ответ. Однако, mod_ssl можно перенастроить в Location блоки, чтобы дать решение для каждого каталога, и может автоматически принудительно повторное согласование параметров SSL для соответствия новой конфигурации. Это можно сделать следующим образом:

 # будь либералом вообще
SSLCipherSuite ВСЕ:!aNULL:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP:+eNULL
<Расположение "/strong/область">
# но https://hostname/strong/area/ и ниже
# требует надежных шифров
SSLCipherSuite HIGH:!aNULL:!MD5
 

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

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

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

После правильной настройки общей поддержки SSL включение OCSP Сшивание обычно требует очень незначительных изменений в файле httpd. конфигурация — добавление этих двух директив:

 SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)" 

Эти директивы размещаются в глобальной области (т. е. не в виртуальной определение хоста) везде, где есть другие глобальные директивы конфигурации SSL. размещены, например, в conf/extra/httpd-ssl.conf для обычного сборки с открытым исходным кодом httpd, /etc/apache2/mods-enabled/ssl.conf для Ubuntu или Debian-в комплекте httpd и т. д.

Путь в директиве SSLStaplingCache (например, журналов/ ) должно совпадать с тем, что указано на Директива SSLSessionCache . Этот путь относительный до Корень сервера .

Эта конкретная директива SSLStaplingCache требует mod_socache_shmcb (от префикса shmcb на аргумент директивы). Этот модуль обычно включен уже для SSLSessionCache или от имени какого-либо модуля, отличного от mod_ssl . Если вы включили кеш сеанса SSL с помощью механизм, отличный от mod_socache_shmcb , используйте эту альтернативу механизм для SSLStaplingCache . Например:

 SSLSessionCache "dbm:logs/ssl_scache"
SSLStaplingCache "dbm:logs/ssl_stapling" 

Вы можете использовать программу командной строки openssl для проверки того, что ответ OCSP отправлено вашим сервером:

 $ openssl s_client -connect www.example.com:443 -status -servername www.example.com
...
Ответ ОССП:
=======================================
Данные ответа OCSP:
    Статус ответа OCSP: успешно (0x0)
    Тип ответа: базовый ответ OCSP
...
    Статус сертификата: Хороший
... 

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

Если для сервера используется несколько SSL-сертификатов

Ответы OCSP хранятся в кэше сшивания SSL. В то время как ответы обычно имеют размер от нескольких сотен до нескольких тысяч байт, mod_ssl поддерживает ответы OCSP размером до 10 КБ. С более чем несколько сертификатов, размер кэша сшивания (32768 байт в примере выше) может надо увеличить. Сообщение об ошибке AH01929 будет зарегистрировано в случае ошибка сохранения ответа.

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

См. Директива SSLStaplingForceURL .

Вы можете подтвердить, что сертификат сервера указывает на ответчик OCSP с помощью программы командной строки openssl следующим образом:

 $ openssl x509 -in ./www.example.com.crt -text | grep 'OCSP.*http'
OCSP — URI: http://ocsp.example.com 

Если указан URI OCSP и веб-сервер может с ним связаться напрямую без использования прокси, никакой настройки не требуется. Обратите внимание, что правила брандмауэра, контролирующие исходящие соединения с веб-сервера, могут нужно отрегулировать.

Если URI OCSP не указан, обратитесь в центр сертификации, чтобы определить, доступен ли он; если это так, настройте его с помощью SSLStaplingForceURL в виртуальном узел, использующий сертификат.

Если настроено несколько виртуальных хостов с поддержкой SSL и OCSP Сшивание должно быть отключено для некоторых

. Добавьте SSLUseStapling Off к виртуальным хостам, для которых OCSP Сшивание должно быть отключено.

Если ответчик OCSP работает медленно или ненадежно

Доступно несколько директив для обработки тайм-аутов и ошибок. Ссылаться к документации по SSLStaplingFakeTryLater , SSLStaplingResponderTimeout и SSLStaplingReturnResponderErrors директивы.

Если mod_ssl регистрирует ошибку AH02217

 AH02217: ssl_stapling_init_cert: Не удается получить сертификат издателя! 

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

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

• Как заставить клиентов проходить аутентификацию с использованием сертификатов?
• Как заставить клиентов аутентифицироваться с использованием сертификатов для определенный URL-адрес, но по-прежнему разрешать произвольным клиентам доступ к остальной части сервера?
• Как разрешить доступ к определенный URL-адрес, но разрешить всем клиентам доступ к остальной части сервера?
• Как я могу требовать HTTPS с надежными шифрами, и либо базовая аутентификация или клиентские сертификаты для доступа к части Интранет-сайт для клиентов, приходящих из Интернета?

Как заставить клиентов проходить аутентификацию с использованием сертификатов?

Когда вы знаете всех своих пользователей (например, как это часто бывает на корпоративном Интранет), вы можете потребовать простой проверки подлинности сертификата. Все вы нужно сделать, это создать клиентские сертификаты, подписанные вашим собственным CA сертификат ( ca. crt ), а затем проверить клиентов по этому сертификат.

 # требуется клиентский сертификат, который должен быть напрямую
# подписано нашим сертификатом ЦС в ca.crt
SSLVerifyClient требует
SSLVerifyDepth 1
SSLCACertificateFile "conf/ssl.crt/ca.crt" 

Как заставить клиентов аутентифицироваться с использованием сертификатов для определенный URL-адрес, но по-прежнему разрешать произвольным клиентам доступ к остальной части сервера?

Чтобы заставить клиентов аутентифицироваться с использованием сертификатов для определенного URL-адреса, вы можете использовать функции реконфигурации для каждого каталога mod_ssl :

 SSLVerifyClient нет
SSLCACertificateFile "conf/ssl.crt/ca.crt"
<Местоположение "/secure/area">
SSLVerifyClient требует
SSLVerifyDepth 1
 

Как разрешить доступ к определенный URL-адрес, но разрешить всем клиентам доступ к остальной части сервера?

Ключом к этому является проверка той части сертификата клиента, соответствует тому, что вы ожидаете. Обычно это означает проверку всех или части Отличительное имя (DN), чтобы узнать, содержит ли оно известную строку. Есть два способа сделать это, используя либо mod_auth_basic или SSLRequire .

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

 SSLVerifyClient нет
SSLCACertificateFile "conf/ssl.crt/ca.crt"
SSLCACertificatePath "conf/ssl.crt"
<Каталог "/usr/local/apache2/htdocs/secure/area">
    SSLVerifyClient требует
    SSLVerifyDepth 5
    SSLOptions+FakeBasicAuth
    SSLRequireSSL
    AuthName "Аутентификация Snake Oil"
    Основной тип авторизации
    Файл AuthBasicProvider
    AuthUserFile "/usr/local/apache2/conf/httpd.passwd"
    Требовать действительного пользователя
 

Пароль, используемый в этом примере, представляет собой зашифрованную строку DES «password». Дополнительные сведения см. в документации SSLOptions . Информация.

httpd.passwd

 /C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA
/C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA
/C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA 

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

 SSLVerifyClient нет
SSLCACertificateFile "conf/ssl.crt/ca.crt"
SSLCACertificatePath "conf/ssl.crt"
<Каталог "/usr/local/apache2/htdocs/secure/area">
  SSLVerifyClient требует
  SSLVerifyDepth 5
  SSLOptions+FakeBasicAuth
  SSLRequireSSL
  SSLRequire %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
               и %{SSL_CLIENT_S_DN_OU} в {"Персонал", "ЦС", "Разработчик"}
 

Как я могу требовать HTTPS с надежными шифрами и базовыми аутентификации или клиентские сертификаты для доступа к части Интранет-сайт для клиентов, приходящих из Интернета? Я все еще хочу разрешить простой HTTP-доступ для клиентов в интрасети.

В этих примерах предполагается, что клиенты в интрасети имеют IP-адреса в диапазоне 192.168.1.0/24 и что часть веб-сайта интрасети, которую вы хотите разрешить доступ в Интернет по адресу /usr/local/apache2/htdocs/subarea . Эта конфигурация должна оставаться за пределами вашего виртуального хоста HTTPS, поэтому что это применимо как к HTTPS, так и к HTTP.

 SSLCACertificateFile "conf/ssl.crt/company-ca.crt"
<Каталог "/usr/local/apache2/htdocs">
    # За пределами подзоны предоставляется доступ только к Интранету
    Требовать IP 192.168.1.0/24

<Каталог "/usr/local/apache2/htdocs/subarea">
    # Внутри подзоны разрешен любой доступ в Интранет
    # а из интернета только HTTPS + Strong-Cipher + Password
    # или альтернативный HTTPS + Strong-Cipher + Client-Certificate
    
    # Если используется HTTPS, убедитесь, что используется надежный шифр.
    # Дополнительно разрешить клиентские сертификаты в качестве альтернативы базовой аутентификации. 192\.168\.1\.[0-9]+$"
    RewriteCond "%{HTTPS}" "!=on"
    Правило перезаписи "." "-" [Ф]
    
    # Разрешить доступ к сети и/или базовую аутентификацию
    Удовлетворить любой
    
    # Контроль доступа к сети
    Требовать ip 192.168.1.0/24
    
    # Базовая HTTP-аутентификация
    Основной тип авторизации
    AuthName "Защищенная область интрасети"
    Файл AuthBasicProvider
    AuthUserFile "conf/protected.passwd"
    Требовать действительного пользователя
 

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

Примечание:
Это не раздел вопросов и ответов.