Let’s encrypt начал выдавать wildcard сертификаты
Let’s Encrypt перешагнул важную веху — с 14 марта каждый может получить бесплатный SSL/TLS сертификат вида *.example.com. Пример установленного сертификата:
https://subdomain.baur.im
https://any-text.baur.im
Вчера Let’s Encrypt официально объявил о запуске ACMEv2 (Automated Certificate Management Environment), который наконец позволяет получить wildcard сертификат. Изначально планировалось начать их выдачу в январе, однако запуск перенесли из-за обнаруженных проблем.
Получение wildcard сертификата сейчас возможно только через DNS challenge, где необходимо временно создать TXT запись вида _acme-challenge.example.com с определенным значением.
Официальный клиент Certbot и некоторые другие клиенты для автоматического обновления сертификатов уже поддерживают staging ACMEv2, версии для production на подходе. И чтобы автоматически пройти DNS challenge уже есть несколько специальных Certbot плагинов. Разумеется, скоро их будет еще больше, в том числе и для сторонних клиентов.
В качестве простейшего примера я вручную получил сертификат на домен, которым владею — baur.im, через браузерный клиент https://www.sslforfree.com. Если я хочу использовать один и тот же сертификат как для суб-доменов, так и для самого домена, то это надо указать явно: baur.im *.baur.im (картинки кликабельны):
Пройдя дальше, предлагается пройти два DNS challenge.
Добавляем обе запрашиваемые TXT записи на суб-домен _acme-challenge.baur.im
И можно скачивать сертификат, который будет действовать 3 месяца.
Теперь эти TXT записи можно удалить. В этом примере для любого суб-домена nginx возвращает статичный html: https://habrahabr.baur.im/.
Обновление nextcloud до версии 17
Для запуска обновления нужно авторизоваться на сервисе под административной записью, проследовать в настройки и открыть «Общие настройки» в административном разделе. Nextcloud показывает установленную версию и версию доступную для обновления, которое можно запустить нажав кнопку «Открыть окно обновления».
После инициации Nextcloud делает резервную копию, скачивает и проверяет целостность файлов обновления, включает режим обслуживания и обновляет файлы. Далее следует вопрос «Keep maintenance mode active»? Здесь нужно быть внимательным. Положительный ответ оставит сайт в режиме обслуживания — предполагается, что администратор знает что дальше делать и сделает это вручную. В противном случае Nextcloud сделает всё сам, поэтому для продолжения нажимаем кнопку «No».
Обновления выполняются итерационно. Сначала Nextcloud 13.x обновится до крайней версии ветки 14.x. После этого нужно будет снова зайти в админцентр и запустить обновление, теперь уже с 14.х до 15.x. И так далее пока не будет достигнута последня возможная актуальная версия.
До обновления
На последних версиях Nextcloud рекомендуется включить PHP OPcache для улучшения производительности. Странно, что этот момент я как-то упустил пару лет назад, так как OPcache появился ещё в PHP 5. В /etc/php/7.2/apache2/php.ini нужно раскомментировать и отредактировать следующие параметры:
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
pcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1Обновление 13.x -> 14.x
Восстанавливаем индексы таблиц:
# sudo -u www-data php /var/www/nextcloud/occ db:add-missing-indicesОбновление 14.x -> 15.x
Подготавливаем базу данных nextcloud для включения четырёхбайтовой кодировки:
# mysql -u root -p
MariaDB [(none)]> ALTER DATABASE nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
MariaDB [(none)]> quitВключаем поддержку четырёхбайтовой кодировки в Nextcloud:
# sudo -u www-data php /var/www/nextcloud/occ config:system:set mysql.utf8mb4 –type boolean –value=”true”Преобразовываем таблицы:
# sudo -u www-data php /var/www/nextcloud/occ maintenance:repairВосстановливаем потерянные индексы таблиц:
# sudo -u www-data php /var/www/nextcloud/occ db:add-missing-indicesПреобразовываем индексы таблиц в bigint:
# sudo -u www-data php /var/www/nextcloud/occ db:convert-filecache-bigintОбновление 15.x -> 16.x
Восстановливаем потерянные индексы таблиц:
# sudo -u www-data php /var/www/nextcloud/occ db:add-missing-indicesПреобразовываем индексы таблиц в bigint:
# sudo -u www-data php /var/www/nextcloud/occ db:convert-filecache-bigintОбновление 16.x -> 17.x
Никаких дополнительных действий не требуется.
Предисловие
Изначально хотелось на Debian 10 установить и настроить Nginx, поверх чего без проблем бы установился актуальный Nextcloud 17. Но для всего этого у меня не получилось выбрать время, поэтому эта статья представляет из себя набор инструкций по обновлению Nextcloud с 13 до актуальной версии 17 с предварительной подготовкой веб-сервера.
Для начала нужно пояснить зачем потребовались радикальные изменения на стороне веб-сервера. Наш сервер основан на актуальном и поддерживаемом Debian 9. Можно просто обновить операционную систему и все компоненты веб-сервера получат как минимум обновления безопасности.
Всё было бы замечательно если бы мы дальше использовали Nextcloud 13 или обновились только до версии 14. Но Nextcloud 13 уже не поддерживается, а поддержка 14-ой версии «на излёте». Начиная с 15-ой версии Nexctcloud будет предлагать преобразовать базу данных в big int для поддержки четырёхбайтовой кодировки и с MariaDB 10.
1 сделать это будет весьма проблематично. Nexctcloud 17 требует PHP 7.1-7.3, в то время как Debian 9 в своих родных репозиториях содержит только версию 7.0. Правильнее, в плане надежности и предсказуемости, было бы обновиться до предпоследней версии Nextcloud, но за пару лет я настолько уверился в надёжности этого сервиса, что мне хотелось обновиться до последней версии и обновить веб-сервер с заделом на будущее.
Поэтому, для обновления до Nexctcloud 17 оптимально обновить MariaDB до актуальной стабильной версии 10.4, а PHP — до 7.2. Именно 7.2, а не актуальной 7.4. Дело в том, что Nextcloud 13 требует PHP 5.6, 7.0 — 7.2, а для Nexctcloud 17 требуется PHP 7.1 — 7.3.
Использовать PHP 7.2 удобно с целью минимизации действий по обновлению. Сервер Apache обновлять не потребуется — достаточно установить обновления безопасности, которые распространяет команда поддержки Debian. А вот для обновлений MariaDB и PHP придётся подключать внешние репозитории.
Когда я только знакомился с Nextcloud я обновлял его «руками»: из консоли специальной командой сайт переводился в режим обслуживания, вручную скачивался и распаковывался архив с новой версией сайта, обновлялись файлы и запускалась процедура обновления.
Такое обновление обычно приводило к ожидаемым результатам, хотя я не ленился делать резервную копию сайта, базы и пользовательских данных. А вот автоматическое обновление порой приводило к всяким сюрпризам. Но это было давно, стабильность движка с тех пор сильно возросла и на этот раз я делал обновления исключительно через веб-интерфес.
Правда от командной строки отвертеться всё равно не удалось. При итерационном обновлении на каждую новую версию в панели управления будут появляться различные предупреждения и уведомления, которые необходимо будет «убирать», осмысленно выполняя команды в командной строке.
Синхронизация с облаком персонального компьютера
Я не считаю себя настоящим программистом. Последние десять лет я программирую на таких языках программирования, которые применяются разве что при разработке процессоров или чипсетов. Ввиду того, что я уже как лет 15 ничего не делал на Си/Си , но что-то автоматизировать на компьютере мне требовалось, я довольно активно применял скриптовые языки типа BAT/CMD или такой софт как Sign 0f Mistery или xStarter. Когда-то я узнал и попробовал что такое AutoIt и это стало новой эрой в моей автоматизации на ПК.
После того как я убедился в стабильности и надёжности системы синхронизации на смартфонах я подумал, что неплохо было бы синхронизировать данные на своём домашнем компьютере. У Nextcloud есть свой клиент для Windows и, естественно, он стал первым кандидатом для испытаний.
Синхронизировать я собирался объём данных порядка терабайта, состоявший из сотен тысяч файлов разного размера. Данные были различны: музыка, картинки, документы, электронные книги, дистрибутивы, резервные копии сайтов и прочее и подобное. Всё это разумно было бы свести к синхронизации более критических данных, например, таких как документы, но мной овладел азарт и хотелось проверить сделанный сервис на прочность.
Спустя десяток часов после начала синхронизации, а по сути первой закачки контента на сервер, клиент запнулся о файл с длинным именем. В то время на сервере я еще использовал подключение внешнего хранилища через VMWare Shared Folders и мне пришлось перепробовать с десяток клиентов, а потом ставить простые эксперименты по ручному копированию файлов на сервер, чтобы понять, что проблема – на стороне сервера.
Так, спустя неделю удачного запуска сервиса, пришлось откатываться на резервную виртуальную машину и отказаться от механизма VMWare Shared Folders, начиная всё сначала. В конце концов, я убрал это узкое место на стороне сервера, протестировал надёжность решения неделей синхронизации смартфонов и решил вновь вернуться к домашнему компьютеру.
На этот раз клиент не споткнулся о злополучный файл и я уже было возрадовался, однако спустя полсуток синхронизации мелких файлов клиент опять подвис. Теперь выяснилось, что слишком длинный путь именно на стороне домашнего компьютера и клиент Nextcloud не может его корректно обработать.
Какое-то время я потратил на то, чтобы найти удобную программу для синхронизации, поддерживающее управление через командную строку. Мне хотелось на каждую крупную папку на компьютере сделать своё задание и запускать их в пакетном режиме. Ранее у меня уже был сделан и отработан набор BAT файлов для синхронизации, используя сценарии и управление FreeFileSync через командную строку.
Проблема длинных путей или имён файлов решалась заданием локальных папок вида «\?D:Info», т.е. по сути обращением к локальной папке как к сетевой. Однако, что такое webdav FreeFileSync не знает. Полных аналогов FolderSync для Windows, к сожалению, не нашлось, но не раз на форумах вместо неё рекомендовали GoodSync и, после кастинга десятка других программ, я решил попробовать его.
GoodSync оказался довольно дружелюбным софтом. Имеется специальная портабельная версия, которая называется GoodSync2Go. Вот она меня и заинтересовала. При установке нужно выбрать букву диска и программа устанавливается на него в папку GoodSync. Я создал папку Sync в корневом каталоге диска, допустим D, и переместил туда созданную папку GoodSync со всем содержимым.
Создаём самоподписанный ssl сертификат с помощью openssl. » my-sertif.ru
Недавно возникла необходимость создать самоподписанный сертификат. Использовал я для этого утилиту OpenSSL и Linux. Собственно этим и хочу с вами поделиться.
Для начала нам необходима ОС Linux, в принципе данная утилита есть и пот Windows, но так как есть linux пользуюсь им. В ОС необходимо установить пакет OpenSSL. Устанавливаем его следующей командой (если под админом можно без «sudo»):
После установки OpenSSL, создаём папки, в которых будут лежать наши сертификаты и ключи, например так:
Приступаем к созданию самоподписанного ssl сертификата. Выполняем команду:
Описание параметров:
Дальше нас попросят ввести пароль к ключу. Вводим пароль, не меньше 4 символов, и повторяем ввод пароля. Затем нас попросят ввести данные о сертификате (информацию о серверной стороне). Если какие-то данные Вам не нужны можете просто ставить точку («.»).
Давайте рассмотрим по порядку, что нам предлагают ввести:
В итоге мы получили два файла, ключ и сертификат. Ключ-это секретный ключ, публичный ключ находиться в теле самого сертификата. Сам сертификат выглядит так:
Ещё можно немного модифицировать наш скрипт, например убрать пароль с секретного ключа, это в большинстве случаев не удобно, если сервис стартует в автоматическом режиме, в тот момент когда ему необходимо будет получить доступ к секретному ключу, нужно будет вручную ввести пароль.
Добавляем параметр «-nodes», в результате секретный ключ не будет зашифрован паролем.
Так же можно ещё добавить параметр «-subj» — этот тот кому принадлежит сертификат, то что мы вводили в интерактивном режиме (название организации, мыло и так далее). Можно эти параметры сразу указать в скрипте. Например так:
В примере выше пропускаем все поля, кроме CN (Common Name).
Для просмотра сертификата можно воспользоваться этой командой:
На этом всё. Не забывайте пользоваться кнопками «Поделиться в соц. сетях», так же подписываться на наш Канал и группы в ВК, Twitter, Facebook.
Всем удачи и море печенек!
Типы ssl-сертификатов и разница между ними
Работаю в хостинге: размещаем сайты пользователей на своих серверах.
Ввиду гигантского количества вопросов, которые нам задают и начинающие, и опытные пользователи, при помощи Пикабу хочу разъяснить некоторые принципы, аспекты и особенности этого ответвления IT-сферы. Не уверен, что количество вопросов от наших пользователей уменьшится, но попытаться стоит.
Даже если вы не пользуетесь хостингом, предположу, что эта информация может быть познавательна.
Сегодня, как я обещал ранее, речь пойдёт о типах SSL-сертификатов, которые можно создать самостоятельно, приобрести за деньги, получить бесплатно, и о разнице между такими сертификатами.
Итак, первый и самый простой способ получить сертификат для своего сайта — купить его. Для этого можно обратиться в любой центр по выпуску сертификатов и заказать сертификат у них, предоставив в процессе заказа информацию, по которой будет проведена проверка. В зависимости от целей и амбиций вы можете выбрать платный сертификат с различными типами проверки данных:
D — сертификаты с проверкой домена. При регистрации такого сертификата производится только проверка доменного имени. Это самый простой в оформлении и дешевый тип SSL сертификатов. Купить такой SSL сертификат может любая организация и любое физическое лицо. При заказе сертификата необходимо указывать “E-mail адрес для подтверждения” в сертифицируемом домене: на этот адрес будет приходить письмо для подтверждения “владения доменом”. То есть, если оформляется сертификат на домен my-sertif.ru, то серт. центр предоставит выбор из нескольких ящиков, который можно будет указать в проверочных данных, например info@my-sertif.ru, admin@my-sertif.ru и другие. Указанный адрес должен обязательно существовать, все письма с инструкциями сертификационного центра будут высылаться на этот E-mail. При этом оформление сертификатов на домены, в имени которых содержатся намёки на банк, финансы и прочие подозрения на “фишинг” невозможно. Если нужен сертификат для домена кредитной организации, то оформление такого сертификата только с проверкой организации. Сайт с таким сертификатом будет показывать в адресной строке браузера «зелёный замочек» (у разных браузеров по-разному).
D O — сертификаты с проверкой домена и организации. В этом случае происходит не только проверка доменного имени, но и принадлежность домена к указанной организации. При посещении сайта защищенного таким сертификатом в адресной строке браузера будет показываться название организации. Перед оформлением необходимо убедиться, что доменное имя было зарегистрировано на организацию, а не на физическое лицо, например, на директора или системного администратора компании. Помимо этого, для некоторых видов сертификатов, необходимо будет заполнить форму с реквизитами организации, для проверки их сертификационным центром.
IDN (Internationalized Domain Names) — поддержка национальных доменов. Поддержка доменов не с латинскими символами. Если у вас домен например в зоне .рф, то такой вид сертификатов — ваш выбор.
EV (Extended Validation) — расширенная проверка. Такие сертификаты получают самое высокое доверие со стороны браузеров. Для этого вида сертификатов проводится полная проверка организации, включая обязательное заполнение форм с данными компании, заверяемых подписью и печатью. Но столь «сложное» оформление даёт самый высокий уровень доверия, чему свидетельствует “зеленая адресная строка” в браузере посетителя сайта, которая говорит о том, что сайт прошёл серьёзную проверку и все данные передаваемые между посетителем и сайтом надёжно защищены.
WildCard — поддержка субдоменов. Wildcard сертификат можно использовать на всех субдоменах (поддоменах) доменного имени. Один такой сертификат будет действителен на доменах www.my-sertif.ru, test.my-sertif.ru, accounts.my-sertif.ru и т.д. без каких либо ограничений на количество субдоменов.
SGC (Server Gated Cryptography) — высокий уровень шифрования. Сертификаты с поддержкой принудительно высокого уровня шифрования обеспечивают максимально высокий уровень шифрования вне зависимости от типов и версий браузеров клиентов. Если пользователь использует старую версию браузера, поддерживающую только 40 или 56 битное шифрование, то при использовании SGC-сертификата соединение все равно будет использовать 128(и более) битное шифрование.
SAN/UCC (United Communications Certificate) — мульти-доменные сертификаты. SAN SSL-сертификаты, так же известные как Единые сертификаты связи (UCC) идеальны для продуктов Microsoft Exchange, а так же для защиты мульти-доменных проектов. Такие сертификаты защищают все описанные в заявке домены, субдомены, локальные имена используя лишь 1 сертификат.
Помимо глубины проверки данных, разные типы сертификатов дают разные страховые возмещения. Об этом стоит рассказать отдельно.
Каждый платный сертификат подразумевает наличии страховки. Страховка покрывает финансовые риски посетителя сайта. Например, сертификат гарантирует страховое возмещение в размере $10000. Значит, если на домене установлен такой сертификат, и посетитель сайта домена в результате операций сайте понёс какие-либо финансовые убытки из-за взлома ключа сертификата, то такие убытки будут покрыты сертифкационным центром вплоть до $10000. На практике же лично мне не известно ни одного случая, когда такое возмещение было бы выплачено. И дело не в том, что SSL настолько суровая технология, что взломать ключи, а, следовательно, подсмотреть шифрованный трафик, невозможно. Скорее очень сложно доказать, что это произошло. Даже когда пару лет назад была анонсирована катастрофическая уязвимость в протоколе SSL, которая получила название «HeartBleed», информации о каких-то возмещениях не было.
Также хочу заметить, что чаще всего самую низкую цену на сертификат вы получите не напрямую у серт.центра, а у посредника. Т.к. они, также как в ситуации с доменами, получают адские скидки из-за оптовых закупок, и, соответственно, могут предложить более низкую цену, чем у самих серт. центров.
Второй способ получить сертификат чуть более сложный. Его можно сгенерировать самостоятельно. Для его воплощения потребуется как минимум командная строка любой unix-системы, пара часов «курения» интернетов по запросам “Генерируем SSL сертификат самостоятельно”, а затем пара несложных команд в командной строке.
В результате будет получен набор файлов, которые в последствии можно использовать для подключения сертификата на домен сайта.
Помимо очевидного минуса в необходимости выполнения каких-то самостоятельных телодвижений, в итоге получится, что для работы с сайтом, использующим такой сертификат, пользователю придётся также лишний раз нажать на пару кнопок в браузере.
Это будет происходить из-за того, что бразуры имеют собственную базу сертификационных центров, сертификатам которых они доверяют. Выпущенный же самостоятельно сертификат так и называется «самоподписанный сертификат». Сертифкационным центром в этом случае выступает компьютер, на котором выпущен сертификат. Соответственно, доверия этому компьютеру у браузера нет. Поэтому бразуер будет выводит сообщение об отсутствии проверки сертификата. Такие сертифткаты лично я рекомендовал бы использовать только для собственных нужд, а в Сети всё-таки пользоваться сертификатами от доверенных серт. центров.
Но что делать, если платить даже 10 северо-американских рублей за сертификат не хочется, но душа требует работать с вашим публичным проектом по зашифрованному каналу? До недавнего времени делать было нечего. Таким образом мы плавно подошли к последнему варианту.
Способ третий. Немного издалека.
Пару лет назад группа интернет-компаний скооперировалась и создала свой собственный лунапарк сертификационный центр, который занимается выпуском бесплатных сертификатов для всех желающих. Центр называется «Let’s Encrypt». Каждый выпускаемый ими сертификат проходит проверку типа D, действует в течение 90 дней, а по истечении этого периода может быть бесплатно перевыпущен. Количество перевыпусков не ограничено.
Именно такой сертификат от Let’s Encrypt я советую почти всем, кто столкнулся с необходимостью использовать SSL.
Для самостоятельного выпуска такого сертификата нужно скачать с сайта организации некоторый софт и запустить его. Ответить на несколько вопросов, которые софт задаст, и дождаться получения файлов сертификата.
Не сочтите за рекламу. Проект не получает никакой финансовой выгоды из выпуска таких сертификатов. Группа компаний лишь ратует за безопасный интернет.
Сейчас уже многие хостеры интегрировали функционал выпуска и перевыпуска таких сертификатов в автоматическом режиме. Например, хостинг панель в нашей компании с последним апдейтом от разработчиков получила новые кнопки, которые позволяют получить сертификат для домена сайта в течение нескольких минут.
картинка кнопок Let’s Encrypt в панели isp
Перевыпуск производится автоматически, поэтому, однажды выпустив такой сертификат, можно вообще забыть о небезопасном соединении со своим проектом. Останется только перевести сайт домена на работу с безопасным протоколом https.
Небольшой бонус. Какой сертификат мне выбрать для своего проекта? Здесь всё достаточно просто.
Всё зависит от того, для чего именно вам нужен сертификат? Большинству пользователей сейчас подойдёт бесплатный сертификат от Let’s Encrypt.
Если вам нужен сертифткат для сайта финаснсового учреждения, то нужно задуматься о платном сертификате с уровнем проверки минимум D O.
Все остальные сертификаты это:
1. Ваши амбиции – зелёная адресная строка в браузере не более, чем понты
2. Финансовые возможности.
3. Техническая необходимость – иногда проще заплатить за мультидоменный сертификат, чем выпускать по сертификату на каждый используемый домен.
Всем спасибо за внимание. Если есть какие-то вопросы – добро пожаловать в комментарии.
P.S.:
Заметил, что по предыдущим моим постам, что они набирают некоторое количество минусов. Рейтинг мне не важен, но хотелось бы понять, что именно в моих постах вызывает негатив. Возможно, я смогу исправить это, если вы будете писать об этом в комментариях.