Перейти к публикации

Linux

  • записи
    2
  • комментариев
    0
  • просмотра
    263

Об этом блоге

Всё, что касается OC Linux. Администрирование серверных и пользовательских систем.

Записи в этом блоге

Настраиваем веб-сервер на базе Apache в Debian / Ubuntu Server

Веб-сервер Apache без преувеличения можно назвать стандартом де-факто в интернет. Большинство популярных систем управления сайтами и иных веб-приложений разрабатываются таким образом, чтобы работать с данным веб-сервером "из коробки". Поэтому, если вам нужен веб-сервер широкого применения, то Apache будет лучшим выбором. В данной статье мы расскажем, как установить и настроить полноценный веб-сервер на базе Debian / Ubuntu Server. Сразу скажем, Apache по многим параметрам, таким как скорость работы или потребление ресурсов, не является лидером среди веб-серверов, но выгодно отличается тем, что на нем гарантированно будет работать любое веб-приложение или сайт без дополнительных настроек и доработок. Добавим сюда гибкость и простоту в настройках, хорошую документацию и низкий порог вхождения. В общем, если вы не знаете какие конкретные выгоды даст вам применение альтернативного веб-сервера, смело выбирайте Apache. Кроме самого веб-сервера нам понадобится система управления базами данных, в данной отрасли стандартом де-факто давно является MySQL, и один из скриптовых языков для работы веб-приложений, на сегодняшний день пальму первенства уверенно держит PHP. Все вместе образует классическую связку, именуемую еще LAMP-сервер, аббревиатура расшифровывается как: Linux - Apache - MySQL - PHP. Для установки мы будем использовать платформу Debian / Ubuntu. Системы, в зависимости от релиза, отличаются набором ПО, но все изложенное ниже будет одинаково применимо к любой из них. Существующие отличия будут оговорены отдельно. На момент написания статьи актуальны следующие релизы систем и версии ПО: Debian 8 Jessie: Apache 2.4.10, PHP 5.6.7, MySQL 5.5.43 Debian 7 Squeeze: Apache 2.2.22, PHP 5.4.39, MySQL 5.5.43 Ubuntu Server 14.04 LTS: Apache 2.4.7, PHP 5.5.9, MySQL 5.5.43 Ubuntu 12.04 LTS: Apache 2.2.22, PHP 5.3.10, MySQL 5.5.43 Все вышеуказанные выпуски содержат относительно современные версии ПО, но есть некоторые особенности. Так входящий в состав Ubuntu 14.04 и Debian 8, Apache 2.4 имеет достаточно серьезные отличия от Apache 2.2 и не все CMS (системы управления контентом, "движки") и веб-приложения умеют работать с ним, особенно это касается старых версий. Так, например, вы не сможете использовать Apache 2.4 для веб-доступа к базам 1С:Предприятие. Поэтому, если вы решили выбрать версию 2.4 - уточните совместимость с нею всех планируемых к размещению CMS и веб-приложений. Кроме того, MySQL из состава Ubuntu Server 12.04 / 14.04 не работает внутри контейнеров OpenVZ, которые широко используются для предоставления услуги VPS. Проблема решается заменой MySQL из репозитория на версию от MySQL Community (разработчики) или один из форков, например, MariaDB. С учетом вышесказанного оптимальным выбором нам представляется использование в качестве платформы веб-сервера Debian 7, как наиболее совместимую с существующими веб-приложениями и не имеющую серьезных проблем. Мы не будем останавливаться на установке и подготовке серверной ОС, более подробно вы можете ознакомиться с этим процессом в наших статьях для Debian и Ubuntu Server. Также не забудьте правильно настроить язык и региональные стандарты системы. Все приведенные ниже действия следует выполнять с правами суперпользователя, например, с помощью команды sudo. Установка Apache Установка веб-сервера предельно проста: apt-get install apache2 Для проверки его работы наберите в браузере IP-адрес сервера, и вы увидите стандартную страницу заглушку: Для Apache 2.4 она выглядит несколько иначе, но смысл от этого не меняется. Настройки сервера содержатся в /etc/apache2/apache2.conf, к которому подключаются дополнительные файлы из директорий mods-enabled и sites-enabled. При этом никто не мешает вам внести все указанные настройки непосредственно в apache2.conf - все будет работать, но это резко снижает удобство администрирования, так как требует постоянной правки основного файла конфигурации, в то время как настройки во внешних файлах легко включаются и отключаются при помощи специальных инструментов. С этой целью каталоги mods-enabled и sites-enabled не содержат файлов конфигурации, а только символические ссылки на директории mods-available и sites-available, где следует располагать сами файлы. Как понятно из названий, в данных каталогах находятся настройки модулей и виртуальных хостов. Если с модулями дело приходится иметь редко, то управлять таким образом виртуальными хостами, т.е. сайтами, очень удобно. Подробно о виртуальных хостах и расположении содержимого сайта мы уже писали в статье по Lighttpd, все сказанное там справедливо и для нашего случая. Вы вольны выбрать любую схему размещения данных, мы же предпочитаем хранить содержимое сайтов внутри /var/www в папках с именем домена. Следующий вопрос, который следует решить, это права доступа к файлам и папкам сайта. По умолчанию их владельцем должен являться веб-сервер (пользователь и группа www-data), в противном случае скрипты могут работать неожиданным образом или не работать вообще. Более удобно и безопасно запускать содержимое сайтов от имени пользователя, а не веб-сервера. Для этого установим следующий пакет: apt-get install apache2-mpm-itk В Ubuntu 14.04 при установке данного пакета вы можете столкнуться с ошибкой: dpkg: error processing package apache2-mpm-itk (--configure): проблемы зависимостей -- оставляем не настроенным Это известный баг, для его исправления выполните: a2dismod mpm_event apt-get install -f Если мы заглянем в папку sites-enabled, то увидим там уже готовую конфигурацию для сайта по умолчанию, т.е. того, что будет показано при наборе IP-адреса сервера. Данная настройка указывает на папку /var/www или /var/www/html для Apache 2.4, где расположена страница заглушка. После того как вы добавите свои сайты, выводиться будет первый по списку сайт. Допустим мы хотим разместить на нашем сервере содержимое сайта example.com, сначала создадим необходимые директории и сделаем их владельцем пользователя, который будет работать с сайтом: mkdir /var/www/example.com chown andrey:andrey /var/www/example.com Теперь создадим файл виртуального хоста и приступим к его заполнению: touch /etc/apache2/sites-available/example.com Для Apache 2.4 файлы конфигурации обязательно должны иметь расширение .conf, поэтому команда будет выглядеть следующим образом. touch /etc/apache2/sites-available/example.com.conf Внутри разместите следующий текст: <VirtualHost 1.2.3.4:80> ServerName example.com ServerAdmin mail@example.com ServerAlias www.example.com DocumentRoot /var/www/example.com CustomLog ${APACHE_LOG_DIR}/example.com.access.log combined ErrorLog ${APACHE_LOG_DIR}/example.com.error.log AssignUserID andrey andrey <Directory /var/www/example.com> Options -Includes -Indexes -ExecCGI AllowOverride All </Directory> </VirtualHost> Разберем содержимое более подробно. Начинается секция виртуального хоста с ее определения <VirtualHost 1.2.3.4:80>, где указывается IP-адрес и порт, на котором данный хост работает, если вы хотите принимать соединения на всех сетевых интерфейсах, то вместо адреса поставьте "звездочку" - *. Внутри секции располагаются следующие директивы: ServerName - имя виртуального хоста, должен иметь значение полного доменного имени (FQDN), в нашем случае example.com, определяет, какое доменное имя обслуживает данный виртуальный хост. ServerAdmin - контактный адрес электронной почты администратора домена, включается в сообщения об ошибках веб-сервера, рекомендуется завести для этих целей отдельный ящик. ServerAlias - алиас имени хоста, обязательно значение www.example.com, чтобы ваш сайт работал как с www, так и без. DocumentRoot - корневая папка виртуального хоста, указываем директорию размещения сайта, т.е. /var/www/example.com CustomLog - имя и расположение лога доступа, переменная ${APACHE_LOG_DIR} указывает на стандартную директорию логов веб-сервера, это позволяет использовать стандартный механизм ротации логов для всех сайтов, в имени лога рекомендуем указывать имя хоста, чтобы сразу было понятно где какой лог. Не забудьте в конце опцию combined, данная опция указывает формат лога и задается в apache2.conf. ErrorLog - имя и расположение лога ошибок, полностью аналогичен логу доступа, но не требуется указывать формат лога. AssignUserID - имя и группа пользователя (через пробел) от имени которых будет работать данный виртуальный хост, задается только если установлен apache2-mpm-itk, в противном случае эта директива не нужна. Внутри секции виртуального хоста размещаем еще одну секцию <Directory /var/www/example.com>, которая включает директивы, применяемые не к хосту, а к каталогу, в нашем случае к корневому каталогу виртуального хоста. Там располагается директива Options, которая содержит следующие опции (перед каждой из которых ставится + или -, разрешая или запрещая опцию): ±Includes - разрешает / запрещает SSI (Server Side Includes -- включения на стороне сервера), в нашем случае выключено в целях безопасности. Имеет смысл включать только в том случае, если ваш сайт явно требует данной опции. ±Indexes - разрешает / запрещает показывать содержимое каталога при отсутствии индексного файла, отключено в целях безопасности. ±ExecCGI - разрешает / запрещает выполнение сценариев CGI, отключаем в целях безопасности. За ней следует директива AllowOverride, которая устанавливает использование директив из файлов .htaccess, по умолчанию сервер устанавливает для /var/www данную директиву в None, что запрещает использовать директивы .htaccess во всех вложенных директориях. Для того чтобы разрешить использование директив .htaccess установите данную директиву в All, что разрешит использовать в .htaccess любые директивы. Этим список доступных опций (как и директив) не исчерпывается, но их рассмотрение выходит за рамки данной статьи и будет рассмотрено в отдельном материале. Вы можете самостоятельно ознакомиться с ними в официальной документации. Закрываем открытые секции: </Directory> и </VirtualHost>, затем сохраняем файл. Конфигурация виртуального хоста готова. Чтобы включить сайт необходимо сделать символьную ссылку на файл конфигурации в каталоге sites-enabled, а, чтобы выключить - удалить эту ссылку. Это можно сделать вручную, при помощи команды ln -s, или использовать специальную утилиту apache: a2ensite example.com Данная команда включит сайт, для выключения введите: a2dissite example.com В качестве опции команде передается имя конфигурационного файла из sites-available, в случае Apache 2.4 без расширения. После каждого такого действия веб-сервер необходимо перезапустить: service apache2 reload Чтобы проверить работу виртуального хоста разместите в его корневой директории любой html-файл и обратитесь к серверу по имени домена (при этом А-запись домена должна быть настроена и указывать на ваш веб-сервер). Например, создадим индексный файл: touch /var/www/examlpe.com/index.html И разместим в нем строку: <body><h1>OK!</h1></body> В итоге в браузере вы должны увидеть следующее: Установка PHP Если веб-сервер был нужен вам для размещения статического содержимого или сторонних веб-приложений, например, публикации баз 1С:Предприятия, то дальше можно не читать. Но если вы собираетесь создать сайт на основе популярных CMS - вам потребуется поддержка скриптового языка PHP, на базе которого разработаны большинство современных "движков". Выполним команду: apt-get install php5 Будет установлен сам интерпретатор и необходимые для работы с веб-сервером модули. Модули позволяют гибко изменять функциональность PHP, управление модулями осуществляется аналогично Apache, когда конфигурации модулей располагаются в одной директории, а для их подключения делается символьная ссылка в другую. По умолчанию PHP устанавливается с базовым набором модулей, который удовлетворяет большинство потребностей, однако применяемая вами CMS может требовать дополнительных модулей, которые нужно будет установить отдельно. Например, для работы с графикой вам потребуется поддержка графической библиотеки GD2, поэтому установим соответствующий модуль: apt-get install php5-gd После чего не забудьте перезапустить веб-сервер: service apache2 reload Кстати, GD2, на наш взгляд не самый лучший выбор, в актив библиотеки можно записать низкое потребление ресурсов и высокую скорость работы, но по качеству работы с изображениями она уступает альтернативной утилите imagemagick, иногда значительно. Поэтому имеет смысл установить обе утилиты и выбрать ту, работа которой наиболее вам подойдет. Если ресурсы сервера позволяют, то предпочтительно использовать imagemagick. Установим утилиту и модуль PHP для нее: apt-get install imagemagick php5-imagick Для проверки работы PHP создадим в корневой директории сайта специальный скрипт: touch /var/www/examlpe.com/info.php И внесем в него следующий текст: <?php phpinfo(); ?> Теперь наберем в браузере http://example.com/info.php, в результате работы данного скрипта вы увидите стандартную страницу с информацией о PHP, установленных модулях, настройках и т.д. Установка MySQL СУБД MySQL - третий необходимый компонент полноценного веб-сервера, основное назначение базы данных - хранение информации сайта, как пользовательской, так и служебной. При этом по важности СУБД превосходит все остальные компоненты, так как потеря базы данных равносильна потере всей информации вашего ресурса. Установим сервер баз данных и модуль PHP для работы с ним: apt-get install mysql-server php5-mysql В процессе установки вам будет предложено ввести пароль для суперпользователя MySQL (root), которого не следует путать с суперпользователем системы. Для удобного управления базами данных имеет смысл установить phpMyAdmin - удобную веб-утилиту для управления сервером MySQL: apt-get install phpmyadmin Инсталлятор утилиты умеет автоматически настраивать популярные веб-сервера Apache и Lighttpd, нужный сервер следует указать при установке: Веб-интерфейс утилиты будет доступен по адресу http://example.com/phpmyadmin, для входа следует использовать учетные данные пользователя MySQL, в нашем случае это root (других еще нет) с паролем, который мы указали во время установки MySQL. В Ubuntu 14.04 мы столкнулись с небольшой проблемой, утилита сообщила нам, что расширение mcryptне найдено, хотя соответствующий модуль PHP был установлен среди зависимостей. Проверим. В /etc/php5/apache2/conf.d ссылка на данный модуль отсутствует, в то время как в /etc/php5/mods-available нужный файл есть. Следовательно, модуль установлен, но, по какой-то причине, не подключен. Возможно это связано с Apache 2.4 и тогда подобная ситуация может иметь место и в Debian 8. Однако ничего страшного не произошло, все что нам нужно - это подключить модуль, создав символьную ссылку: ln -s /etc/php5/mods-available/mcrypt.ini /etc/php5/apache2/conf.d/20-mcrypt.ini Никаких дополнительных настроек MySQL сервер не требует, благо кодировка UTF-8 стала стандартом де-факто. В принципе на этом можно закончить, но все базы данных размещаемые на сервере будут работать с правами суперпользователя MySQL, что небезопасно. Поэтому следует создать пользователей сервера баз данных с ограниченными правами, чтобы они могли управлять только своими базами. Откроем phpMyAdmin и перейдем на страницу Привилегии (Пользователи), где выберем Добавить нового пользователя. Теперь прокрутим страничку чуть ниже и установим опцию Предоставить полные привилегии на базы данных подпадающие под шаблон (имя пользователя\_%) Это позволит лишний раз не отвлекаться на установку прав, а просто создавать базы с именами вида ivanov_base1 или petrov_base2, предоставляя соответствующим пользователям полные права на них, а также быстро определять принадлежность баз данных. В тоже время данная настройка не является догмой, вы можете поступать на свое усмотрение. Остальные параметры оставляем по умолчанию. Для проверки создадим базу данных phpMyAdmin - Базы данных - Новая база данных. При создании БД обращайте внимание на кодировку. Сегодня большинство движков и веб-приложений работают с UTF-8 (utf8_general_ci), однако старые версии движков могут использовать национальные кодировки, поэтому нужно будет правильно указать их еще на стадии создания базы, в противном случае, залив в базу, созданную в UTF-8 дамп в кодировке Windows-1252 вместо русских букв на сайте окажутся "крякозяблики". Создав базу, проверим ее привилегии, нажав одноименную ссылку рядом с именем базы. Как видим, все правильно, полные права на базу имеет указанный в имени пользователь и суперпользователь root, хотя никаких настроек доступа при создании базы мы не указывали. На этом настройку можно считать законченной и приступать к эксплуатации сервера. Несмотря на то, что описанная конфигурация является базовой, ее возможностей вполне достаточно для размещения и нормальной работы практически любой современной CMS массового применения и мы будем использовать данный сервер как эталонный для наших следующих материалов по данной теме.

k010v

k010v

Получаем сертификаты Let's Encrypt при помощи Certbot

Начиная цикл статей о шифровании при помощи сертификатов Let's Encrypt мы упоминали Certbot как официальный клиент. Несмотря на простоту, его установка и использование может таить некоторые подводные камни, особенно для начинающих, и поэтому мы решили посвятить ему отдельную статью, чтобы более не возвращаться к данному вопросу. Также мы рекомендуем ознакомиться с данной статьей и более опытным пользователям, особенно если вы планируете в дальнейшем использовать наши материалы по SSL. Что такое Certbot? Это клиент протокола ACME предназначенный для автоматического управления SSL-сертификатами от Let's Encrypt, он позволяет полностью автоматизировать процесс получения и продления сертификата, а при использовании соответствующих плагинов даже может автоматически конфигурировать веб-сервер или иное, использующее сертификат приложение. Все дальнейшие инструкции будут предназначены для пользователей актуальных версий Debian и Ubuntu, но многое будет справедливо и для иных дистрибутивов Linux. Установка в Debian 8 Jessie Debian 8 является на сегодня основной "рабочей лошадкой" в своем семействе. Однако в официальных репозиториях Certbot отсутствует и для его установки вам потребуется подключить специальный backports-репозиторий. Он содержит скомпилированные для использования в среде текущего дистрибутива пакеты из более новых версий, которые могут быть недостаточно стабильными или иметь некоторые иные проблемы, поэтому использовать его следует с осторожностью. Откроем файл /etc/apt/sources.list и добавим в него следующую строку: deb http://ftp.debian.org/debian jessie-backports main Затем обновим список пакетов: apt-get update Теперь установим пакет с явным указанием репозитория: apt-get install certbot -t jessie-backports Так как Certbot написан на Python при его установке будет автоматически подтянуто довольно большое количество python-пакетов по зависимостям, однако это не должно вызвать каких-либо проблем. Установка в Debian 9 Stretch В новом выпуске Debian все просто, отныне Certbot представлен в официальном списке пакетов и для его установки достаточно выполнить одну простую команду: apt-get install certbot В остальном процесс ничем не отличается от Jessie, также будет подтянуты необходимые python-зависимости. Установка в Ubuntu 14.04/16.04 В отличие от разработчиков Debian в Ubuntu пошли другим путем, оформив Certbot в виде отдельного PPA. Данная технология позволяет любому желающему создать собственный репозиторий и хорошо известна любому пользователю Ubuntu, однако вся ответственность за содержимое PPA лежит только на их авторах, поэтому использовать их следует с определенной долей осмотрительности и осторожности. Прежде всего установим необходимое для работы с PPA программное обеспечение: apt-get install software-properties-common Затем добавим нужный PPA: add-apt-repository ppa:certbot/certbot Обновим список пакетов: apt-get update и установим Certbot: apt-get install certbot Последовательность действий для всех дистрибутивов Ubuntu одинаковая, при подключении PPA автоматически определяется выпуск Ubuntu и добавляются нужные репозитории. Точно также можно установить Certbot на промежуточные релизы (16.10 или 17.04) но мы не рекомендуем их использование в производственных средах. Подготовка к получению сертификатов В предыдущей статье цикла мы довольно подробно разбирали работу плагина webroot, который позволяет автоматически получать сертификаты используя уже установленный в системе веб-сервер. Если коротко, то вы указываете путь к корневой директории сайта, для которого получаете сертификат в файловой системе, Certbot создает там необходимую структуру папок и размещает необходимый для проверки файл. В случае с одним доменом это не вызывает проблем, но если их много или вам требуется сертификат сразу на несколько доменов (основной домен и поддомены), корневые директории у которых отличаются, то у вас возникнут затруднения. Поэтому сам Let's Encrypt рекомендует перейти в таком случае на единую точку подтверждения сертификатов. Сделать это несложно, и мы сейчас расскажем, как. В доступной для веб-сервера директории создадим отдельную папку, скажем, letsencrypt, которую затем мы будем использовать для всех обслуживаемых доменов и установим ее владельцем веб-сервер: mkdir /var/www/letsencrypt chown www-data:www-data /var/www/letsencrypt Теперь нам нужно сделать так, чтобы любой запрос вида: http://example.com/.well-known/acme-challenge приводил к физическому размещению: /var/www/letsencrypt/.well-known/acme-challenge Это несложно, но для каждого из веб-серверов делается по-разному, ниже мы рассмотрим самые популярные из них. Apache 2.x Apache является самым распространенным и популярным веб-сервером, актуальной версией является 2.4.x, для его подготовки к работе с Certbot добавьте в основной конфигурационный файл /etc/apache2/apache2.conf следующую секцию: Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/ <Directory "/var/www/letsencrypt/.well-known/acme-challenge/"> Options None AllowOverride None ForceType text/plain Require all granted RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)" </Directory> Для устаревшей версии Apache 2.2 данный блок должен выглядеть следующим образом: Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/ <Directory "/var/www/letsencrypt/.well-known/acme-challenge/"> Options None AllowOverride None ForceType text/plain Order allow,deny Allow from all RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)" </Directory> Данная секция создает для любого запроса к /.well-known/acme-challenge алиас (псевдоним), указывающий на физическую директорию /var/www/letsencrypt/.well-known/acme-challenge, а ее расположение в основном конфигурационном файле позволит распространить действие директив для любого обслуживаемого домена. Остальные параметры задают необходимые параметры безопасности. Nginx Nginx - второй по популярности веб-сервер (и первый среди продвинутых пользователей) предполагает несколько иной подход к настройке. Для каждого виртуального хоста в секцию server следует добавить блок: location ^~ /.well-known/acme-challenge/ { default_type "text/plain"; root /var/www/letsencrypt; } location = /.well-known/acme-challenge/ { return 404; } Если вы настраивали сервер по нашей инструкции, то мы рекомендуем вынести указанный блок в отдельный шаблон, например, /etc/nginx/templates/letsencrypt.conf и впоследствии подключать в конфигурацию виртуального хоста именно его и в общих чертах это должно выглядеть так: server { server_name example.com .. include /etc/nginx/templates/letsencrypt.conf; } Данный подход является хорошей практикой, так как в случае внесения каких-либо изменений их придется делать только в одном месте, вне зависимости от числа обслуживаемых виртуальных хостов. Lighttpd В русскоязычной среде данный веб-сервер недостаточно распространен, так как пользователи отдают предпочтение Nginx, но в мировом масштабе он входит в число наиболее популярных веб-серверов. Если вы используете именно его, то откройте основной конфигурационный файл /etc/lighttpd/lighttpd.conf и убедитесь, что в секции server.modules присутствует значение mod_alias, в противном случае его необходимо добавить. После чего дополните конфигурацию следующей секцией: $HTTP["url"] =~ "^/.well-known/" { server.document-root = "/var/www/letsencrypt/.well-known/" alias.url = ( "/.well-known/" => "/var/www/letsencrypt/.well-known/" ) dir-listing.activate = "enable" } Не забывайте, что после внесения изменений в конфигурационные файлы любой веб-сервер необходимо перезапустить. Регистрация в Let's Encrypt Да, вы не ошиблись, именно регистрация. Обычно этот пункт пропускают, так как регистрация автоматически выполняется при первом получении сертификата. Но так как мы подробно разбираем работу Certbot, то решили коротко коснуться и этого момента. Регистрация нужна для формирования ключевой пары, которой впоследствии подписываются все запросы, что позволяет удостовериться в подлинности отправителя. Это важно, так как все запросы передаются по открытым каналам и теоретически возможен их перехват и модификация. Адрес электронной почты указываемый при регистрации используется для рассылки уведомлений, например, при неудачной попытке продления сертификата, поэтому следует указывать рабочий ящик, лучше всего собственный. Один и тот-же адрес можно использовать для регистрации на разных хостах, ограничений по этому параметру нет.   Для регистрации выполните команду: certbot register -m admin@example.com Для успешного прохождения процедуры вам потребуется всего-лишь согласиться с условиями использования. Учетная информация будет сохранена в каталог /etc/letsencrypt/accounts, если содержимое данной директории будет утрачено, то вы не сможете продлить сертификаты и вам придется получать их заново, создав новый аккаунт. Это следует учитывать, например, при переносе системы на новый сервер. Если вам необходимо изменить адрес электронной почты аккаунта, скажем при смене администратора, то это можно сделать командой: certbot register --update-registration -m new_admin@example.com Следует помнить, что технической возможности восстановления аккаунта нет и в случае его утраты вам придется заново выпускать все сертификаты. Получение сертификата Наконец-то мы подошли к самому главному - получению сертификата, но не стоит спешить, количество запросов на сертификат в единицу времени ограничено (20 запросов на регистрацию в неделю и 5 неудачных запросов в час), поэтому следует убедиться, что все сделано правильно. Для этого следует использовать возможность тестового запуска Certbot, наберем в консоли: certbot certonly --dry-run --webroot -w /var/www/letsencrypt -d example.com -d www.example.com Ключ --dry-run включает тестовый режим, при котором производится симуляция получения сертификата,--webroot - указывает используемый плагин, после ключа -w указываем путь к директории для letsencrypt, а затем через ключ -d указываем домены для которых мы получаем сертификат. Как минимум это должно быть основное имя сайта и имя c www, хотя никто не мешает включить вам в сертификат все нужные поддомены или вообще разные домены. Лимит на количество доменов в сертификате равен 100. При удачном прохождении теста вы получите краткий ответ: А в случае неудачи довольно развернутый лог, который обычно легко позволяет понять, что именно пошло не так и оперативно исправить ошибки: После того как тестовый запуск увенчался успехом можно переходить к получению сертификата: certbot certonly --webroot -w /var/www/letsencrypt -d example.com -d www.example.com Сертификат получен, отлично! Но где нам его искать? Перейдем в /etc/letsencrypt/live где для каждого полученного сертификата будет создана папка с именем первого указанного в запросе домена, т.е. для нашего примера - example.com. Внутри будут находиться четыре файла: cert.pem - собственно сертификат chain.pem - цепочка доверия, включает корневой и промежуточный сертификаты Let's Encrypt fullchain.pem - полная цепочка, включающая кроме содержимого chain.pem сам сертификат privkey.pem - закрытый ключ сертификата, данный файл является секретным. Именно эти файлы следует использовать в конфигурационных файлах служб при настройке SSL, конкретные реализации выходят за рамки данной статьи и это будет сделано в отдельных материалах, мы же заглянем еще глубже под капот. При внимательном рассмотрении выяснится, что файлы в директории live являются символьными ссылками на аналогичные файлы в /etc/letsencrypt/archive:   Настоящие файлы хранятся в аналогичной по структуре директории archive и имеют в наименовании порядковый номер, который увеличивается при каждом продлении сертификата. Например, при первом получении сертификата ссылка cert.pem из live будет указывать на cert1.pem из archive, после продления туда добавится cert2.pem, и ссылка начнет указывать на него. Как видим процесс обновления сертификатов реализован прозрачно для использующих их служб и достаточно все настроить один единственный раз, остальное Certbot берет на себя. Следует отметить и то, что старые файлы сертификатов не удаляются, это позволяет избежать ошибок в том случае, если какие-то службы оказались неправильно настроены и не смогли переключиться на новый сертификат. Они продолжат работу по защищенному протоколу, но посетители начнут получать сообщение об ошибке сертификата. Полученный сертификат можно в любой момент расширить, добавив в него новые домены, для этого следует использовать ключ --expand: certbot certonly --webroot -w /var/www/letsencrypt --expand -d example.com -d www.example.com -d forum.example.com Таким образом вы всегда можете добавить в сертификат нужные домены не затрагивая остальной инфраструктуры, напомним, что лимит составляет 100 доменов на один сертификат. Продление сертификатов После того, как все сертификаты получены и настроены сайты и службы их использующие встает вопрос об их продлении. Мы помним, что срок действия сертификата - 90 дней, поэтому если их много и получены они в разное время, то вручную следить за всем этим хозяйством будет весьма и весьма проблематично. Поэтому основное назначение Certbot - это именно автоматическое продление сертификатов. Производится оно одной простой командой renew. Если мы заглянем в /etc/cron.d то найдем там файл certbot в котором дважды в день запланирован запуск команды: certbot -q renew Как видим, никаких дополнительных параметров не передается, и Cerbot сам определяет что нужно продлевать. Каким образом он это делает? Вернемся в /etc/letsencrypt и заглянем еще в одну директорию renewal, там мы обнаружим некие конфигурационные файлы с именами доменов, например, example.com.conf, откроем его. В начале будут перечислены файлы сертификата и пути к ним, эта информация нас мало интересует, гораздо интереснее вторая часть файла, которая выглядит примерно так: # Options used in the renewal process [renewalparams] authenticator = webroot installer = None account = 4073d66415ef4c5a89e2cbca53e5f899 [[webroot_map]] example.com = /var/www/letsencrypt www.example.com = /var/www/letsencrypt forum.example.com = /var/www/letsencrypt Секция renewalparams указывает основные параметры получения сертификата: плагин - webroot, инсталлятор сертификата - в нашем случае отсутствует и аккаунт, к которому привязаны данные сертификаты. В секции webroot_map перечислены требующие продления домены и указан путь к корневой папке для Let's Encrypt. Здесь скрыт один из подводных камней, допустим сначала у вас был один домен, и вы просто получали сертификат для него указывая: --webroot -w /var/www/example.com Затем доменов стало больше, и вы перешли на единую точку подтверждения сертификатов /var/www/letsencrypt, но в конфигурационном файле по-прежнему останется /var/www/example.com и такой домен автоматически продлиться не сможет. Поэтому мы рекомендуем всегда проверять возможность продления командой: certbot renew --dry-run Как и в случае с получением сертификата ключ --dry-run предписывает провести тестовый запуск с симуляцией продления, что позволит своевременно выявить возможные ошибки и устранить их. Сама же команда renew, как многие успели догадаться, последовательно получает конфигурационные файлы из директории renewal и выполняет продление согласно указанным там параметрам. В принципе, убедившись в успешности тестового продления можно оставить все как есть, но лучше произвести тонкую настройку. Прежде всего добавим к команде продления ключ --allow-subset-of-names: certbot -q renew --allow-subset-of-names Данный ключ предписывает получать сертификат для неполного набора доменов, это нужно для того, чтобы если один из доменов, перечисленных в сертификате вдруг окажется недоступным, сертификат был получен для остальных. Простой пример из жизни. Вы собираетесь провести серьезную переработку сайта, для этого вы создаете новый домен new.example.com и производите разработку и тестирование на нем, его же вы добавляете в сертификат. Затем вы переносите новый сайт на основной домен, а старый перемещается на old.example.com, который также добавляется в сертификат. Через какое-то время кто-то отключает new.example.com за ненадобностью и потом в одно не очень прекрасное утро сайт "порадует" вас просроченным сертификатом. Но это еще не все, после того как сертификат будет продлен нужно перезапустить все службы его использующие, например, веб-сервер. Можно прописать еще одно задание в cron, но правильно будет сделать по-другому. Certbot поддерживает специальные ключи, которые позволяют выполнять некие действия перед и после запуска утилиты: --pre-hook PRE_HOOK - позволяет выполнять некие действия перед запуском certboot --post-hook POST_HOOK - выполняет указанные действия после запуска certboot --renew-hook RENEW_HOOK - выполняет действия только после успешного продления сертификата. Наиболее удобным в использовании является ключ --renew-hook, который будет перезапускать службы только тогда, когда получит новый сертификат, а не два раза в день, как это будет делать --post-hook. Как использовать данные ключи? В простейшем случае можно просто добавить их к команде продления в cron: certbot -q renew --allow-subset-of-names --renew-hook "service apache2 reload; service vsftpd restart" В указанном нами примере будут перезапущены веб-сервер Apache и ftp-сервер vsftpd. Однако разные сертификаты могут быть привязаны к разным службам, поэтому более правильно будет указать эти параметры в конфигурационных файлах в директории renewal. Для этого в секцию [renewalparams]добавьте: renew-hook = service apache2 reload; service vsftpd restart Обратите внимание на синтаксис, который несколько отличается от синтаксиса, используемого при указании в составе команды. Надеемся, что данный материал поможет вам лучше понять работу Certboot, что в дальнейшем позволит нам не обращаться этой теме, а уделить больше внимания конкретным реализациям защиты c помощью SSL для различных приложений.

k010v

k010v



  • Блоги

    • CentOS

      • 13
        записей
      • 1257
        комментариев
      • 17365
        просмотров
    • web-администрирование

      • 3
        записи
      • 0
        комментариев
      • 257
        просмотров
    • Mikrotik

      • 11
        записей
      • 225
        комментариев
      • 21973
        просмотра
    • LAN

      • 5
        записей
      • 0
        комментариев
      • 1168
        просмотров
    • Windows

      • 17
        записей
      • 12
        комментариев
      • 962
        просмотра
    • Asterisk

      • 2
        записи
      • 0
        комментариев
      • 91
        просмотр
    • Разное

      • 1
        запись
      • 0
        комментариев
      • 331
        просмотр
    • 1C

      • 1
        запись
      • 0
        комментариев
      • 240
        просмотров
    • Linux

      • 2
        записи
      • 0
        комментариев
      • 263
        просмотра
    • iOS

      • 1
        запись
      • 0
        комментариев
      • 273
        просмотра
×