How To Create a Self-Signed SSL Certificate for Apache in Ubuntu 20.04

Содержание

Используемые термины: Apache, CentOS, Ubuntu, FreeBSD.

Инструкция написана для операционных систем на базе UNIX.

Получение сертификата
Модуль Apache для работы с SSL
Настройка веб-сервера
Проверка
Редирект с http на https
Apache + NGINX

How To Create a Self-Signed SSL Certificate for Apache in Ubuntu 20.04

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

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

Создание двухуровневой иерархии ЦС и подпись ssl сертификата

Идем на RootCA и создаем центр сертификации:

cd ~
wget -P ~/ https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.8/EasyRSA-3.0.8.tgz
tar xvf EasyRSA-3.0.8.tgz
mv ~/EasyRSA-3.0.8 ~/easyrsa-rootca/
cd ~/easyrsa-rootca/
cp vars.example vars
vim vars

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

#set_var EASYRSA_REQ_COUNTRY    "US"
#set_var EASYRSA_REQ_PROVINCE   "California"
#set_var EASYRSA_REQ_CITY           "San Francisco"
#set_var EASYRSA_REQ_ORG            "Copyleft Certificate Co"
#set_var EASYRSA_REQ_EMAIL          "me@example.net"
#set_var EASYRSA_REQ_OU     "My Organizational Unit"

Далее находим следующие установки, удалим # и редактируем их значения. Эти директивы отвечают за сроки жизни сертификатов (первая — за срок сертификата ЦС, вторая — за срок сертификата, который подписывается, третья — за сертификат с данными об отозванных сертификатах):

#set_var EASYRSA_CA_EXPIRE          3650         #-->  3650
#set_var EASYRSA_CERT_EXPIRE    3650         #-->  1825
#set_var EASYRSA_CRL_DAYS            180

После редактирования файла vars и установки необходимых нам значений создадим ЦС:

./easyrsa init-pki
./easyrsa build-ca nopass

Если будет только один CA (RootCA), то переходим к выпуску сертификатов.
Теперь переходим на SubCA и повторяем те же самые шаги с небольшими изменениями:

cd ~
wget -P ~/ https://github.com/OpenVPN/easy-rsa/releases/download/v3.0.8/EasyRSA-3.0.8.tgz
tar xvf EasyRSA-3.0.8.tgz
mv ~/EasyRSA-3.0.8 ~/easyrsa-subca/
cd ~/easyrsa-subca/
cp vars.example vars
vim vars

Находим блок, удалим # и подставим свои значения:

#set_var EASYRSA_REQ_COUNTRY    "US"
#set_var EASYRSA_REQ_PROVINCE   "California"
#set_var EASYRSA_REQ_CITY           "San Francisco"
#set_var EASYRSA_REQ_ORG            "Copyleft Certificate Co"
#set_var EASYRSA_REQ_EMAIL          "me@example.net"
#set_var EASYRSA_REQ_OU     "My Organizational Unit"

Далее находим следующие установки, удалим # и редактируем их значения:

#set_var EASYRSA_CA_EXPIRE          3650         #-->  1825
#set_var EASYRSA_CERT_EXPIRE    3650         #-->  365
#set_var EASYRSA_CRL_DAYS            180

Еще раз создадим ЦС и запрос на подпись сертификата и передадим его RootCA:

./easyrsa init-pki
./easyrsa build-ca subca nopass
scp pki/reqs/ca.req user@ip_RootCA:/tmp

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

cd ~/easyrsa-rootca/
./easyrsa import-req /tmp/ca.req SubCA
./easyrsa sign-req ca SubCA
scp pki/issued/SubCA.crt user@ip_SubCA:/tmp
scp pki/ca.crt user@ip_SubCA:/tmp/RootCA.crt

Переходим на SubCA и перемещаем подписанный сертификат в ЦС. Дабы в будущем не путаться в сертификатах, оставим имя сертификата SubCA.crt и сделаем на него символьную ссылку:

mv /tmp/SubCA.crt ~/easyrsa-subca/pki/
ln -s ~/easyrsa-subca/pki/SubCA.crt ~/easyrsa-subca/pki/ca.crt

Идем в директорию ЦС и создадим файл Диффи-Хелмана для повышения безопасности web-сервера. Файл Диффи-Хелмана (Diffie-Hellman) необходим для реализации протокола, позволяющего использовать небезопасный канал для получения общего секретного ключа. Этот ключ будет в дальнейшем использоваться для защищенного обмена данными с помощью алгоритмов симметричного шифрования.

cd ~/easyrsa-subca/
./easyrsa gen-dh

Переходим к финальной части, а именно выпуск ssl сертификата и конфигурация web-сервера:

./easyrsa gen-req your_site_name nopass
./easyrsa sign-req server you_site_name

Создадим директорию для хранения сертификатов, перенесем туда сертификаты и подпишем запрос:

mkdir -p ~/ssl_cert/name_web_server
mv pki/dh.pem ~/ssl_cert/name_web_server/
cp pki/SubCA.crt ~/ssl_cert/name_web_server/
cp pki/{issued,private}/your_site_name.* ~/ssl_cert/name_web_server/
sudo rm pki/reqs/your_site_name.req

Для работы сервера нам надо сделать цепочку сертификатов (объединить сертификат your_site_name.crt и SubCA.crt в fullchain.crt):

cat ~/ssl_cert/name_web_server/your_site_name.crt ~/ssl_cert/name_web_server/SubCA.crt > ~/ssl_cert/name_web_server/your_site_name.fullchain.crt

Cертификаты готовы, и нам надо перенести их на web-сервер и указать к ним путь:

sudo chown -R user:user ~/ssl_cert/name_web_server     #(optional)
scp ~/ssl_cert/name_web_server/*.{crt,key,pem} user@ip_web_server:/tmp

Идем на web-сервер создадим директорию для хранения сертификатов и перенесем их туда:

mkdir ~/ssl_cert/
mkdir ~/ssl_cert/{key,cert}
sudo chmod 600 ~/ssl_cert/key/
mv /tmp/*.{crt,pem} ~/ssl_cert/cert/
sudo mv /tmp/*.key ~/ssl_cert/key/

Пропишем пути к сертификатам в Apache2 или Nginx.

sudo vim /etc/nginx/sites-available/your_site_name.com

Находим блок с путями к сертификатам и меняем его:

...
listen 443 ssl; 

    ssl_certificate /home/user/ssl_cert/cert/your_site_name.fullchain.crt;
    ssl_certificate_key /home/user/ssl_cert/key/your_site_name.com.key;
    ssl_dhparam /home/user/ssl_cert/cert/dh.pem;
...

systemctl restart nginx

sudo vim /etc/apache2/sites-available/your_site_name.com.conf

Находим блок с путями к сертификатам и меняем его (данная схема подходит для Apache2 версии 2.4.8 и новее):

...
SSLCertificateFile      /home/user/ssl_cert/cert/your_site_name.fullchain.crt
SSLCertificateKeyFile /home/user/ssl_cert/key/your_site_name.key
SSLOpenSSLConfCmd DHParameters /home/user/ssl_cert/cert/dh.pem
...

Для Apache2 версии 2.4.7 и ниже объединяем сертификаты и редактируем конфигурацию:

cat /home/user/ssl_cert/cert/your_site_name.fullchain.crt /home/user/ssl_cert/cert/dh.pem > /home/user/ssl_cert/cert/your_site_name.dhfullchain.pem
sudo vim /etc/apache2/sites-available/your_site_name.com.conf

...
SSLEngine On
  SSLCertificateFile /home/user/ssl_cert/cert/your_site_name.dhfullchain.pem
  SSLCertificateKeyFile /home/user/ssl_cert/key/your_site_name.key
...

systemctl restart apache2

Осталось сделать последний ход: на web-сервере мы разместили самоподписанный сертификат, значит для любого клиента этот сертификат не является надежным и безопасным. Для этого мы должны дать системе корневой сертификат и сказать, что всем сертификатам, которые подписаны этим ЦС и его подчиненными ЦС, мы можем доверять. Для этого мы берем сертификат RootCA.crt отдаем пользователям, которые будут ходить на наш web-сервер и устанавливаем в систему как «доверенные корневые центры сертификации». Теперь у нас все готово и можно работать дальше.

Скрипты для автоматизации создания ssl сертификатов и их отзывов

Прежде чем запустить скрипт мы должны создать инфраструктуру для хранения сертификатов и сами скрипты. Данные скрипты мы поместим на сервере SubCA, он у нас подписывающий. Скрипты можно отправить копипастом на сервер или установить git и клонировать репозиторий.
В процессе создания пользовательские сертификаты будут экспортироваться в формат .p12 именно такой формат ключа и нужен пользователя, для доступа к серверу. В процессе экспорта ключа будет запрошена парольная фраза (пароль) и тут есть один нюанс, а именно для windows и linux систем она не обязательна — это на ваше усмотрение, а вот для macOS нужна. Ниже я объясню каким образом наиболее безболезненно установить сертификат на системе macOS, потому что там приходится доставать бубен и исполнять танец дождя.

Установим git и клонируем репозиторий:

apt install git -y
git clone https://github.com/dumasti/create_ssl.git
mkdir -p ~/ssl_scripts/ssl_certs
mv create_ssl/*.sh ssl_scripts/
rm -r create_ssl
chmod +x ~/ssl_scripts/*.sh

Если скрипты не клонируем, тогда создадим необходимые директории:

mkdir -p ~/ssl_scripts/ssl_certs
touch ~/ssl_scripts/{create_ssl,revoke_ssl}.sh
chmod +x ~/ssl_scripts/*.sh

Теперь в файлы запишем сам скрипт:

vim ~/ssl_scripts/create_ssl.sh

#!/bin/bash

echo "For whom/for what the certificate? ((S)erver/(U)ser/(C)ancel) "
while true; do
        read -r
        object=$REPLY
        if [[ "$object" == "S" ]] || [[ "$object" ==  "s" ]]; then
                echo "What is the name of your site? "
                read -r
                name=$REPLY
                break
        elif [[ "$object" == "U" ]] || [[ "$object" ==  "u" ]]; then
                echo "What is the name of your user? "
                read -r
                name=$REPLY
                break
        elif [[ "$object" == "C" ]] || [[ "$object" == "c" ]]; then
                exit
        else
                echo "Correct answer is S/s/U/u/C/c only!"
        fi
done
echo "Which CA to use? "
echo `ls ~/ | grep -E -i 'CA|easy|rsa'`
read -r
ca=$REPLY
cd ~/$ca/
echo "How long to sign the certificate (in days)?
365 - 1 year
730 - 2 years
1095 - 3 years
1460 - 4 years
1825 - 5 years "
read -r
year_new=$REPLY
mkdir -p ~/ssl_scripts/ssl_certs/$name
year_old=`cat ~/$ca/vars | grep "set_var EASYRSA_CERT_EXPIRE"`
sed -i "s/$year_old/set_var EASYRSA_CERT_EXPIRE $year_new/" ~/$ca/vars
./easyrsa gen-req $name nopass
if [[ "$object" == "S" ]] || [[ "$object" ==  "s" ]]; then
        ./easyrsa sign-req server $name
        echo "Do you need dh.pem? (y/n)"
        read -r
        dh=$REPLY
        if [[ "$dh" == "y" ]]; then
                if [ -e pki/dh.pem ]; then
                        mv pki/dh.pem ~/ssl_scripts/ssl_certs/$name
                else
                        ./easyrsa gen-dh
                        mv pki/dh.pem ~/ssl_scripts/ssl_certs/$name
                fi
        fi
        cp ~/$ca/pki/issued/$name.crt ~/ssl_scripts/ssl_certs/$name
        cp ~/$ca/pki/RootCA.crt ~/ssl_scripts/ssl_certs/$name
        cp ~/$ca/pki/private/$name.key ~/ssl_scripts/ssl_certs/$name
        cat ~/$ca/pki/issued/$name.crt ~/$ca/pki/SubCA.crt > ~/ssl_scripts/ssl_certs/$name/$name.fullchain.crt
elif [[ "$object" == "U" ]] || [[ "$object" ==  "u" ]]; then
        ./easyrsa sign-req client $name
        ./easyrsa export-p12 $name
        cp ~/$ca/pki/issued/$name.crt ~/ssl_scripts/ssl_certs/$name
        cp ~/$ca/pki/RootCA.crt ~/ssl_scripts/ssl_certs/$name
        cp ~/$ca/pki/private/$name.{key,p12} ~/ssl_scripts/ssl_certs/$name
fi
echo "$name `date | cut -d " " -f2,3,4` $ca $year_new $object  CREATE" >> ~/ssl_scripts/cert_base
cd ~/ssl_scripts/ssl_certs/
tar -cvf $name/$name.tar $name/*
tar -czvf $name/$name.tar.gz $name/*
whoami=`whoami`
sudo chown -R $whoami:$whoami ~/ssl_scripts/ssl_certs/$name/
echo "DONE!"

Хочу отметить тот факт, что хоть скрипт и предлагает подписывать сертификат на 5 лет, но iOS устройства считают такие сертификаты ненадежными и для поддержки таких устройств сертификаты нужно подписывать не больше чем на 3 года.

Читать также:  Безопасная электронная подпись Rutoken Light 64kb электронная открытка с уникальным сертификатом

vim ~/ssl_scripts/revoke_ssl.sh

#!/bin/bash

echo "Which CA to use? "
echo `ls ~/ | grep -E -i 'CA|easy|rsa'`
read -r
ca=$REPLY
cd ~/$ca/
echo "For whom/for what to revoke the certificate? ((S)erver/(U)ser/(C)ancel) "
echo `ls pki/issued/ | cut -d '.' -f 1`
read -r
name_crt=$REPLY
if [ -e ~/ssl_scripts/ssl_certs/revoke ]; then
        printf "yes" | ./easyrsa revoke $name_crt
        ./easyrsa gen-crl
        cp pki/crl.pem ~/ssl_scripts/ssl_certs/revoke/
else
        mkdir ~/ssl_scripts/ssl_certs/revoke
        printf "yes" | ./easyrsa revoke $name_crt
        ./easyrsa gen-crl
        cp pki/crl.pem ~/ssl_scripts/ssl_certs/revoke/
fi
rm ~/$ca/pki/issued/$name_crt.crt
rm ~/$ca/pki/private/$name_crt.*
rm -r ~/ssl_scripts/ssl_certs/$name_crt
echo "$name_crt `date | cut -d " " -f2,3,4` $ca REVOKE" >> ~/ssl_scripts/cert_base
echo "DONE!"

Данные скрипты интерактивны, их нужно только запустить, а после отвечать на вопросы.

Настройка доступа к web-серверу по сертификатам

Бывают такие случаи, когда нужно ограничить доступ к сайту, но не закрывать сервер или сайт от доступа извне (из интернета). В таких случаях можно прибегнуть к простому решению, а именно разрешить доступ на сайт только по пользовательскому ssl сертификату. Сервер его проверит и если все устроит, то пустит пользователя. Выше я уже привел скрипты, которые сами все сделают, вам надо только ответить на вопросы для чего/кого выпускается сертификат и срок «жизни» сертификата. Скрипты заточены под двухуровневую иерархию, а значит будут работать на SubCA. Для тех, кто хочет выпускать сертификаты имея только один центр сертификации приведу тут инструкцию. Она проста: для начала возвращаемся в начало статьи и создаем CA как там (RootCA). Далее мы выпускаем сертификат для веб сервера и, если нужна авторизация пользователей по ssl, клиента:

cd ~/easyrsa-rootca/
./easyrsa gen-dh
./easyrsa gen-req <FQDN> nopass
./easyrsa sign-req server <FQDN>
mkdir -p ~/ssl_cert/<FQDN>
cp pki/dh.pem ~/ssl_cert/<FQDN>/
cp pki/private/<FQDN>.key ~/ssl_cert/<FQDN>/
cp pki/issued/<FQDN>.crt ~/ssl_cert/<FQDN>/
# Если нужна авторизация пользователей, то
./easyrsa gen-req <user_name> nopass
./easyrsa sign-req client <user_name>
./easyrsa export-p12 <user_name>
mkdir ~/ssl_cert/<user_name>
cp pki/private/dara.p12 ~/ssl_cert/<user_name>/
cp pki/ca.crt ~/ssl_cert/{<FQDN>,<user_name>}/RootCA.crt

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

Конфигурация для Apache2 и Nginx проста, нам надо только добавить пару строк и прописать путь к сертификату. Приступим:

vim /etc/nginx/sites-available/your_site_name.com

...
ssl_client_certificate       /home/user/ssl_cert/cert/RootCA.crt;
ssl_verify_client            on;
ssl_verify_depth            1;
#ssl_crl                        /home/user/ssl_cert/cert/crl.pem; # --убрать комментарий для активации отзыва сертификатов
...

systemctl restart nginx

image

vim /etc/apache2/sites-available/your_site_name.com.conf

...
SSLCACertificateFile /home/user/ssl_cert/cert/RootCA.crt
#SSLCARevocationFile /home/user/ssl_cert/cert/crl.pem # --убрать комментарий для активации отзыва сертификатов
SSLVerifyClient require
SSLVerifyDepth  10
...

systemctl restart apache2

Apache на Windows

Настройка авторизации в Windows не отличается от Debian за исключением пути к conf файлу:

C:\Apache24\conf\httpd.conf

Далее прописываем настройка в конце файла и указываем пути к сертификатам:

LoadModule ssl_module modules/mod_ssl.so
Listen 443
<VirtualHost *:443>
    ServerAdmin webmaster@localhost

    #DocumentRoot "${SRVROOT}/htdocs"
    DocumentRoot "C:\Apache24\htdocs"
    ServerName localhost:443
    ServerAlias www.localhost:443

    ErrorLog "${SRVROOT}/logs/error-ssl.log"
    TransferLog "${SRVROOT}/logs/access-ssl.log"

    SSLEngine on
    SSLCertificateFile      "C:\Apache24\localhost\localhost.fullchain.crt"
    #SSLCertificateFile      "C:\Apache24\localhost\localhost.crt"
    SSLCertificateKeyFile "C:\Apache24\localhost\localhost.key"
    SSLOpenSSLConfCmd DHParameters "C:\Apache24\localhost\dh.pem"
    SSLCACertificateFile "C:\Apache24\localhost\RootCA.crt"
    #SSLCARevocationFile "C:\Apache24\localhost\crl.pem"

    SSLVerifyClient require
    SSLVerifyDepth  10
</VirtualHost>

Сохраняем настройки и перезапускаем Apache в PowerShell (запускаем от имени администратора):

c:\Apache24\bin\httpd.exe -k restart

Когда все готово осталось попасть на сайт используя пользовательский ssl сертификат. Выпускаем сертификат используя скрипт выше или своим способом, который не запрещен религией и устанавливаем этот сертификат. Как я уже говорил выше, сертификат можно запаролить при выпуске. Самое главное — сертификат должен быть с расширением .p12.

Установка на macOS

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

Сервера поднимал тут.
Благодарю за внимание!

Благодарность за помощь

Благодарю за редакторские правки Дарью, а так же за проверку и тестирование мануала Станислава.

How To Create a Self-Signed SSL Certificate for Apache in Ubuntu 20.04

Шаг 2. Установка модуля SSL для Apache

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

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

Спускаемся к шагу 3 данной инструкции.

Иначе, устанавливаем httpd ssl_module.

а) Для CentOS:

yum install mod_ssl

б) Для Ubuntu/Debian:

в) Для FreeBSD:

Открываем файл конфигурации apache:

* подразумевается, что используется apache 2.4.

#<IfModule ssl_module>
#SSLRandomSeed startup builtin
#SSLRandomSeed connect builtin
#</IfModule>

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

systemctl restart httpd

service apache2 restart

* первая, как правило, используется в системах на базе RPM, вторая — DEB, третья — BSD.

Шаг 4. Проверка работоспособности

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

Если сайт не заработал, пробуем найти причину по log-файлу. Как правило, он находится в каталоге /var/log/apache или /var/log/httpd.

Шаг 5. Настройка редиректа

Чтобы все запросы по http автоматически перенаправлялись на https, необходимо настроить перенаправление (redirect). Есть несколько способов это сделать.

В конфигурационном файле

Открываем файл с настройкой виртуальных доменов (как в шаге 3) и дописываем следующее:

* в конкретном примере, мы перенаправили все запросы для сайта site.ru.
** обратите особое внимание, что если у Вас уже есть VirtualHost *:80 для настраиваемого сайта, необходимо его закомментировать или отредактировать.

В файле .htaccess

Установка модуля rewrite

Чтобы перенаправление работало в Apache, необходимо установить модуль rewrite.

а) в CentOS открываем конфигурационный файл и проверяем наличие строки:

LoadModule rewrite_module modules/mod_rewrite.so

systemctl restart httpd

б) в Ubuntu:

systemctl restart apache2

Шаг 3. Настройка Apache

Выходим из папки ssl:

Открываем файл с настройкой виртуальный доменов.

* где site.conf — конфигурационный файл для конкретного сайта

В открытый файл добавляем следующее:

<VirtualHost *:443>
    ServerName site.ru
    DocumentRoot /var/www/apache/data
    SSLEngine on
    SSLCertificateFile ssl/cert.pem
    SSLCertificateKeyFile ssl/cert.key
    #SSLCertificateChainFile ssl/cert.ca-bundle
</VirtualHost>

  • ServerName — домен сайта;
  • DocumentRoot — расположение файлов сайта в системе;
  • SSLCertificateFile и SSLCertificateKeyFile — пути до файлов ключей, которые были сгенерированы на шаге 1;
  • SSLCertificateChainFile — при необходимости, путь до цепочки сертификатов (если используем не самоподписанный сертификат).

Проверяем корректность настроек в Apache:

Перечитываем конфигурацию apache:

Шаг 1. Создание сертификата

Для боевого сервера, сертификат должен быть получен от доверенного центра сертификации — либо локального для компании, либо коммерческого. Или получен бесплатно от Let’s Ecnrypt.

Читать также:  Удаленный узел не прошел проверку не удалось выполнить проверку отзыва сертификата 1с

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

а) на Red Hat / CentOS:

б) на Debian / Ubuntu:

в) во FreeBSD:

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

mkdir ssl ; cd ssl

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

openssl req -new -x509 -days 1461 -nodes -out cert.pem -keyout cert.key -subj «/C=RU/ST=SPb/L=SPb/O=Global Security/OU=IT Department/CN=test.dmosk.local/CN=test»

* в данном примере созданы открытый и закрытый ключи на 4 года (1461 день); значения параметра subj могут быть любыми в рамках тестирования.

Apache + NGINX

При использовании веб-сервера на базе и Apache и NGINX, как правило, наружу смотрит последний. В таком случае, именно он будет отвечать на http-запросы, и в таком случае нужно настраивать SSL на NGINX.

HTTPD — Apache2 интернет сервер

Apache — наиболее используемый интернет-сервер на линукс системах. Интернет-сервера используются для выдачи интернет-страниц по запросу клиентских компьютеров. Клиенты обычно запрашивают и просматривают интернет-страницы используя приложения интернет-браузеров, таких как Firefox, Opera, Chromium или Mozilla.

Пользователи вводят единообразный указатель ресурсов (URL) для определения интернет-сервера по его полностью квалифицированному доменному имени (FQDN) и пути до требуемого ресурса. Например, чтобы увидеть домашнюю станицу интернет-сайта Ubuntu, пользователь должен ввести только FQDN: 

www.ubuntu.com
www.ubuntu.com/community

Наиболее распространенный протокол, используемый для передачи интернет-страниц, — это гипертекстовый протокол передачи (HTTP). Такие протоколы, как HTTP поверх SSL (HTTPS) и протокол передачи файлов (FTP) — протокол для загрузки и получения файлов, также используются.

Интернет-сервера Apache обычно используются в комбинации с движком базы данных MySQL, языком сценариев гипертекстового препроцессора (PHP) и другими популярными языками сценариев, таких как Python И Perl. Эта конфигурация получила название LAMP (Linux, Apache, MySQL and Perl/Python/PHP) и формирует мощную и крепкую платформу для разработки и развертывания интернет-приложений.

Установка

Интернет-сервер Apache2 доступен в Ubuntu Linux. Для установки Apache2:

  1. В терминале введите следующую команду: 

sudo apt-get install apache2

Настройка

Apache2 настраивается помещением инструкций (directives) в обычные тестовые файлы настроек. Эти инструкции разделены между следующими файлами и каталогами:

  1. apache2.conf: основной файл настроек Apache2. Содержит глобальные настройки для всего Apache2.

  2. conf.d: (каталог) содержит файлы настроек, которые применяются глобально к Apache2. Другие пакеты, которые используют Apache2 для предоставления контента, могут добавлять файлы или символьные ссылки в этот каталог.

  3. envvars: файл, где устанавливаются переменные окружения Apache2.

  4. httpd.conf: устаревший основной файл настроек Apache2, названный по имени сервиса httpd. Теперь этот файл обычно пустой, поскольку большинство опций настроек были перемещены в каталоги, упомянутые далее. Файл может быть использован для для специфичных настроек пользователя, имеющих глобальный эффект в Apache2.

  5. mods-available: этот каталог содержит конфигурационные файлы как для загрузки модулей, так и для их настройки. Тем не менее не все модули имеют отдельные файлы настройки.

  6. mods-enabled: содержит символьные ссылки на файлы в /etc/apache2/mods-available. Когда создается символьная ссылка на файл настроек модуля, он включается при следующем рестарте apache2.

  7. ports.conf: содержит инструкции, которые определяют какие TCP порты прослушивает Apache2.

  8. sites-available: этот каталог содержит файлы настроек для виртуальных сетевых узлов (Virtual Hosts) Apache2. Виртуальные сетевые узлы позволяют настраивать Apache2 на множество сайтов с отдельными конфигурациями.

  9. sites-enabled: подобно mods-enabled содержит символьные ссылки на каталог /etc/apache2/sites-available. Аналогично, когда файл настроек из sites-available получает здесь символьную ссылку, соответствующий ему сайт будет активен при следующем перезапуске Apache2.

В дополнение к этому другие файлы настроек могут быть добавлены с использованием инструкции Include, а символы группировок могут использоваться для включения множества файлов настроек. Любая инструкция может быть добавлена в любой из этих файлов настроек. Изменения в основных конфигурационных файлах распознаются только после старта или рестарта Apache2.

Сервер также читает файлы, содержащие типы mime документов; имя файла задается инструкцией TypesConfig, обычно через /etc/apache2/mods-available/mime.conf, который также может включать дополнения и переопределения, а по умолчанию используется /etc/mime.types.

Общие настройки

Этот раздел рассматривает существенные параметры настройки сервера Apache2. Обратитесь к документации по Apache2 для уточнения деталей.

1. Apache2 по умолчанию поставляется с конфигурацией, дружественной к виртуальным хостам. Это означает, что он изначально настроен с единственным виртуальным хостом (используя инструкцию VirtualHost) который может быть изменен или использоваться как есть, если у вас единственный сайт, либо использоваться как шаблон для дополнительных виртуальных хостов, если у вас несколько сайтов. Если оставить его единственным, изначальный виртуальный хост будет обслуживать ваш сайт по умолчанию или пользователи сайта заметят, что введенный ими URL не совпадает с инструкцией ServerName любого из ваших созданных сайтов. Для изменения начального виртуального хоста отредактируйте файл /etc/apache2/sites-available/default.

Инструкции, установленные для виртуального хоста, влияют только на соответствующий виртуальный хост. Если инструкция установлена на весь сервер и не установлена в настройках виртуального хоста, используется общая настройка. Например, вы можете определить email адрес вебмастера и не определять его отдельно для каждого виртуального хоста.

Если вы хотите настроить новый виртуальный хост или сайт, скопируйте этот файл в тот же каталог с новым именем. Например: 

sudo cp /etc/apache2/sites-available/default /etc/apache2/sites-available/mynewsite

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

3. Инструкция Listen определяет порт, и в общем случае IP адрес, на которых Apache2 должен ожидать соединения. Если IP адрес не определен, Apache2 будет прослушивать все IP адреса, которые назначены компьютеру, где он запущен. Значение по умолчанию для Listen 80. Замените его на 127.0.0.1:80 чтобы Apache2 прослушивал только интерфейс внутренней петли, что сделает его недоступным из интернета; на 81 (например) для изменения порта доступа или оставьте как есть для стандартного функционирования. Эта инструкция может быть найдена и изменена в единственном файле /etc/apache2/ports.conf.

4. Инструкция ServerName необязательная и определяет на какой адрес FQDN ваш сайт должен отвечать. Изначальный виртуальный хост не имеет ServerName, поэтому отвечает на все запросы не соответствующие директивам ServerName других виртуальных хостов. Если вы приобрели доменное имя ubunturocks.com и хотите прописать его на вашем Ubuntu сервере, значение ServerName для файла настроек вашего виртуального хоста должно быть ubunturocks.com. Добавьте эту инструкцию в файл нового виртуального хоста, который вы создавали ранее (/etc/apache2/sites-available/mynewsite).

Возможно вы захотите, чтобы ваш сайт откликался на www.ubunturocks.com, поскольку многие пользователи считают префикс www необходимым. Используйте для этого инструкцию ServerAlias. Вы можете также применять для ServerAlias групповые символы.

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

ServerAlias *.ubunturocks.com

5. Инструкция DocumentRoot определяет где Apache2 будет искать файлы, которые являются содержимым сайта. По умолчанию используется значение /var/www, как определено в /etc/apache2/sites-available/default. Если желаете, можете изменить это значение в файле сайта вашего виртуального хоста и не забудьте создать этот каталог, если необходимо!

Включите новый VirtualHost, используя утилиту a2ensite, и перезапустите Apache2: 

sudo a2ensite mynewsite
sudo service apache2 restart

Убедитесь, что заменили mynewsite на более понятное имя для VirtualHost. Один из способов это называть файл по значению ServerName виртуального хоста.

Читать также:  Что такое социальный сертификат на получение государственной муниципальной услуги в социальной сфере

Аналогично используйте утилиту a2dissite для выключения сайтов. Это может быть полезным при разрешении проблем с несколькими виртуальными хостами: 

sudo a2dissite mynewsite
sudo service apache2 restart

Настройки по умолчанию

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

1. DirectoryIndex — это страница по умолчанию, выдаваемая сервером, когда пользователь запрашивает индекс каталога указанием прямого слеша (/) после его имени.

2. Инструкция ErrorDocument позволяет вам определить файл для Apache2, используемый при определенных ошибочных событиях. Например, если пользователь запросил ресурс, который не существует, возникнет ошибка 404. По умолчанию Apache2 просто вернет код возврата HTTP 404. Прочитайте /etc/apache2/conf.d/localized-error-pages для детальных инструкций по использованию ErrorDocument, включающий расположение файлов примеров.

3. По умолчанию сервер пишет журнал обмена в файл /var/log/apache2/access.log. Вы можете поменять это для каждого сайта в файлах настроек ваших виртуальных хостов с помощью инструкции CustomLog или спуститься на уровень настроек по умолчанию, определяемых в /etc/apache2/conf.d/other-vhosts-access-log. Вы можете также определить файл, в который будут сохраняться ошибки, через инструкцию ErrorLog, которая изначально указывает на var/log/apache2/error.log. Они хранятся отдельно от журнала обмена чтобы помочь в решении проблем с вашим сервером Apache2. Вы можете также определить LogLevel (изначально значение «warn») и LogFormat (смотрите /etc/apache2/apache2.conf для значений по умолчанию).

4. Некоторые опции задаются на уровне каталогов вместо уровня сервера. Options — одна из таких директив. Раздел Directory заключается в XML-подобные теги, как показано ниже: 

<Directory /var/www/mynewsite>
...
</Directory>

Инструкция Options внутри раздела Directory принимает одно или несколько из следующих значений (среди прочего), разделенные пробелами:

  • ExecCGI — Разрешает выполнение CGI сценариев. CGI сценарии не выполняются, если данная опция не выбрана.

Большинство файлов не должны выполняться как CGI сценарии. Это может быть очень опасно. CGI сценарии должны находиться в отдельном каталоге и вне вашего DocumentRoot. И только для этого каталога должна указываться опция ExecCGI. Так сделано изначально и по умолчанию CGI сценарии располагаются в /usr/lib/cgi-bin.

  • Includes — Позволяет включения на стороне сервера. Включения на стороне сервера позволяют файлам HTML включать другие файлы. Смотрите документацию Apache SSI (сообщества Ubuntu) для дополнительных деталей.

  • IncludesNOEXEC — Позволяет включения на стороне сервера, но блокирует команды #exec и #include в CGI сценариях.

  • Indexes — Показывает форматированный список содержимого каталога, если не найдены DirectoryIndex (как например index.html) в запрашиваемом каталоге.

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

  • Multiview — Поддерживает зависящие от содержимого просмотры; эта опция по умолчанию выключена по соображениям безопасности. Смотрите документацию Apache2 по этой опции.

  • SymLinksIfOwnerMatch — Следует по символическим ссылкам если целевой файл или каталог имеет того же владельца, что и ссылка.

Настройки httpd

Этот раздел раскрывает некоторые основные конфигурационные настройки сервиса httpd.

LockFile — инструкция LockFile устанавливает путь к блокирующему файлу (lockfile) когда сервер скомпилирован с опцией USE_FCNTL_SERIALIZED_ACCEPT или USE_FLOCK_SERIALIZED_ACCEPT. Он должен сохраняться на локальном диске. Стоит оставить значение по умолчанию если только каталог журналов не расположен на NFS ресурсе. В противном случае исходное значение стоить изменить на каталог локального диска с правами на чтение только для root.

PidFile — инструкция PidFile устанавливает файл, в который сервер записывает ID своего процесса (pid). Этот файл должен быть доступен на чтение только root. В большинстве случаев этот параметр стоит оставить без изменений.

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

Модули Apache2

Apache2 — модульный сервер. Это означает, что только самая базовая функциональность включена в ядро сервера. Расширенные возможности доступны через модули, которые могут быть загружены в Apache2. По умолчанию базовый набор модулей включается в сервер на этапе компиляции. Если сервер скомпилирован для использования динамически загружаемых модулей, то модули могут быть скомпилированы отдельно и добавлены в любое время с использованием инструкции LoadModule. В противном случае Apache2 должен быть перекомпилирован для добавления или удаления модулей.

Ubuntu компилирует Apache2 с возможностью динамической загрузки модулей. Конфигурационные директивы могут быть включены по условию присутствия соответствующего модуля в блоке <IfModule>.

Вы можете установить дополнительные модули Apache2 и использовать их с вашим интернет сервером. Например, запустите следующую команду в терминале для установки модуля авторизации MySQL: 

sudo apt-get install libapache2-mod-auth-mysql

Ищите дополнительные модули в каталоге /etc/apache2/mods-available.

Используйте утилиту a2enmod для включения модуля: 

sudo a2enmod auth_mysql
sudo service apache2 restart

Аналогично a2dismod выключит модуль: 

sudo a2dismod auth_mysql
sudo service apache2 restart

Настройка HTTPS

Модуль mod_ssl добавляет важную возможность для сервера Apache2 — возможность шифрованных соединений. Таким образом, когда ваш браузер соединяется с использованием SSL, используется префикс https:// в начале адреса URL в строке навигации.

Модуль mod_ssl доступен в пакете apache2-common. Выполните следующую команду в терминале для включения этого модуля: 

sudo a2enmod ssl

Настройки по умолчанию для HTTPS находятся в файле /etc/apache2/sites-available/default-ssl. Чтобы Apache2 предоставлял HTTPS, также требуются файлы ключа и сертификата. Изначальная настройка HTTPS использует сертификат и ключ, созданные пакетом ssl-cert. Они подходят для тестирования, но должны быть заменены на сертификат, соответствующий вашему сайту или серверу. Для информации по созданию ключей и получению сертификатов смотрите раздел Сертификаты.

Для настройки Apache2 для HTTPS введите следующее: 

sudo a2ensite default-ssl

Каталоги /etc/ssl/certs и /etc/ssl/private используются по умолчанию. Если вы установили сертификат и ключ в другие каталоги, убедитесь что изменили соответственно опции SSLCertificateFile и SSLCertificateKeyFile.

С Apache2, теперь настроенным на HTTPS, перезапустим сервис для разрешения новых настроек: 

sudo service apache2 restart

В зависимости от того как вы выпускали свой сертификат, вам может потребоваться ввести кодовую фразу при старте Apache2.

Вы можете получить доступ к страницам защищенного сервера набрав https://your_hostname/url/ в адресной строке вашего браузера.

Права разделения записи

Чтобы более одного пользователя имели право записи в один и тот же каталог, необходимо дать право записи группе, которая их объединяет. Следующий пример предоставляет права на запись в каталог /var/www для группы «webmasters». 

sudo chgrp -R webmasters /var/www
sudo find /var/www -type d -exec chmod g=rwxs "{}" \;
sudo find /var/www -type f -exec chmod g=rws  "{}" \;

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

Ссылки

  2. Apache Cookbook от O’Reilly — отличный ресурс по созданию специфичных настроек для Apache2.

  3. Для вопросов по Apache2 в Ubuntu используйте IRC канал #ubuntu-server на freenode.net.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

➤