На krivoshein.site у меня стоит не бесплатный Let’s Encrypt, а платный сертификат GlobalSign (AlphaSSL). Решение старое: захотелось нормальную цепочку, предсказуемый срок действия и минимум сюрпризов на старых устройствах. Сертификат давно истекал, поэтому я занялся продлением и заодно записал весь процесс — от панели FirstVDS до конфига Nginx на WordOps.
Ниже — практичный разбор без маркетинга: что именно я нажимал в панели, какие файлы пришли от GlobalSign и как я их разложил по серверу.
Где и как я продлевал сертификат
Сертификат для krivoshein.site у меня оформлен через панель FirstVDS. В разделе SSL-сертификатов у них довольно прямолинейный интерфейс: выбираешь домен, продлеваешь заказ, дальше начинается стандартная история с CSR и подтверждением домена.
CSR у меня уже был, а приватный ключ я храню на сервере, поэтому брать новый ключ не пришлось. В панели FirstVDS я заполнил данные владельца (ФИО, e-mail, телефон) и выбрал подтверждение домена через DNS TXT-запись. Для GlobalSign это классический вариант.
Подтверждение домена через DNS TXT
После оформления заказа панель FirstVDS выдала строку вида:
_globalsign-domain-verification=XXXXXXXXXXXX...
Эту запись нужно добавить в DNS для домена krivoshein.site. В моём случае DNS живёт у регистратора, так что всё свелось к добавлению TXT-записи в зону. Через некоторое время GlobalSign проверяет запись, домен подтверждается, и сертификат уходит на выпуск.
После выпуска в панели FirstVDS стали доступны файлы сертификата. Я скачал набор архивов и отдельный CSR, но нас интересует именно zip с готовыми сертификатами.
Что прислал GlobalSign: разбираем файлы
Из архива от FirstVDS/GlobalSign я получил набор файлов примерно следующего вида:
- www_krivoshein_site.crt — основной сертификат для домена www.krivoshein.site (в SAN обычно и сам krivoshein.site);
- GlobalSign GCC R6 AlphaSSL CA 2025.crt — промежуточный сертификат центра сертификации;
- GlobalSign.crt — корневой сертификат GlobalSign;
- www_krivoshein_site.p7b — PKCS#7-пакет с тем же содержимым, больше полезен для IIS/Windows.
Отдельно у меня есть приватный ключ, который я ранее генерировал на сервере. Он выглядит как стандартный блок:
-----BEGIN RSA PRIVATE KEY----- ...закрытый ключ... -----END RSA PRIVATE KEY-----
Показывать его где-либо кроме сервера — плохая идея, так что в блоге он живёт только в виде заглушки.
Готовим директорию под сертификат на сервере
Сервер с krivoshein.site у меня крутится на WordOps, поверх Nginx. Чтобы не размазывать ключи и сертификаты по системе, я использую отдельную директорию для домена:
mkdir -p /etc/ssl/krivoshein.site cd /etc/ssl/krivoshein.site
Сюда же я кладу приватный ключ:
nano /etc/ssl/krivoshein.site/www_krivoshein_site.key
Вставляю туда блок с приватным ключом, сохраняю и закрываю. Права ставлю минимально необходимые:
chmod 600 /etc/ssl/krivoshein.site/www_krivoshein_site.key chown root:root /etc/ssl/krivoshein.site/www_krivoshein_site.key
Дальше копирую на сервер zip с сертификатами из панели FirstVDS и распаковываю:
cd /etc/ssl/krivoshein.site unzip /root/14836355.zip
В итоге в каталоге оказываются файлы GlobalSign GCC R6 AlphaSSL CA 2025.crt, GlobalSign.crt и www_krivoshein_site.crt плюс p7b.
Собираем fullchain и ca-bundle
Для Nginx обычно нужно два файла:
- fullchain — основной сертификат плюс цепочка до корневого;
- ca-bundle (для ssl_trusted_certificate) — цепочка CA, которую сервер использует для stapling и проверки.
Fullchain
Fullchain я собрал так:
cd /etc/ssl/krivoshein.site
cat www_krivoshein_site.crt \
GlobalSign\ GCC\ R6\ AlphaSSL\ CA\ 2025.crt \
> fullchain.crt
chmod 644 fullchain.crt
chown root:root fullchain.crt
Этого достаточно для большинства клиентов: они получают сертификат сайта и промежуточный сертификат, дальше уже опираются на доверенные корневые сертификаты из своей системы.
CA bundle
Для ssl_trusted_certificate я сделал отдельный файл, куда сложил промежуточный и корневой сертификаты:
cat GlobalSign\ GCC\ R6\ AlphaSSL\ CA\ 2025.crt \
GlobalSign.crt \
> ca-bundle.crt
chmod 644 ca-bundle.crt
chown root:root ca-bundle.crt
Этот файл nginx использует, в частности, для OCSP stapling.
Проверяем, что ключ подходит к сертификату
Перед тем как трогать конфиг, я всегда проверяю, что приватный ключ действительно от этого сертификата, а не от прошлого набора. Делается это через сравнение модулей:
cd /etc/ssl/krivoshein.site openssl x509 -noout -modulus -in www_krivoshein_site.crt | openssl md5 openssl rsa -noout -modulus -in www_krivoshein_site.key | openssl md5
Если хэши совпали — пара ключ/сертификат корректная, можно двигаться дальше. Если нет — где-то перепутан ключ, и лучше остановиться и разобраться до того, как сервер уйдёт в ошибку.
Настройка Nginx/WordOps под новый сертификат
В WordOps SSL-конфиг для сайта у меня лежит в /var/www/krivoshein.site/conf/nginx/ssl.conf. В нём я указываю пути к только что собранным файлам:
listen 443 ssl; listen [::]:443 ssl; ssl_certificate /etc/ssl/krivoshein.site/fullchain.crt; ssl_certificate_key /etc/ssl/krivoshein.site/www_krivoshein_site.key; ssl_trusted_certificate /etc/ssl/krivoshein.site/ca-bundle.crt; ssl_stapling on; ssl_stapling_verify on;
HTTP/2 и HTTP/3 (QUIC) у меня тоже включены, но они просто используют те же пути к сертификатам.
Редирект с http на https реализован отдельным блоком на 80 порту:
server {
listen 80;
listen [::]:80;
server_name krivoshein.site www.krivoshein.site;
return 301 https://$host$request_uri;
}
Проверка конфига и перезагрузка nginx
После правки конфигов первым делом проверяю синтаксис:
nginx -t
Если выводит, что syntax is ok и test is successful, перезагружаю nginx:
systemctl reload nginx
На этом этапе сайт уже должен отдавать новый сертификат. Но я всегда дополнительно проверяю даты и цепочку через openssl с клиентской стороны:
openssl s_client -connect krivoshein.site:443 -servername krivoshein.site \
</dev/null 2>/dev/null | openssl x509 -noout -dates -issuer -subject
В моём случае результат показывает срок действия до января 2027 года и issuer GlobalSign GCC R6 AlphaSSL CA 2025 — значит, продление прошло успешно, и наружу уходит именно новый сертификат.
Краткий чеклист продления SSL через FirstVDS
Чтобы в следующий раз не вспоминать по шагам, сохраняю себе короткий чеклист:
- В панели FirstVDS продлить заказ SSL для krivoshein.site.
- Выбрать подтверждение через DNS TXT, добавить запись _globalsign-domain-verification в зону домена, дождаться выпуска сертификата.
- Скачать архив с сертификатами из панели FirstVDS.
- На сервере в /etc/ssl/krivoshein.site:
- убедиться, что там лежит приватный ключ www_krivoshein_site.key с правами 600;
- распаковать архив, получить www_krivoshein_site.crt, GlobalSign GCC R6 AlphaSSL CA 2025.crt и GlobalSign.crt;
- собрать fullchain.crt (сертификат + промежуточный CA);
- собрать ca-bundle.crt (промежуточный + корневой CA);
- проверить совпадение модулей у ключа и сертификата через openssl.
- В ssl.conf nginx/WordOps прописать пути к fullchain.crt, ключу и ca-bundle.crt.
- Сделать nginx -t и reload, проверить сертификат через openssl s_client.
Итог
Продление платного SSL-сертификата через FirstVDS в связке с Nginx и WordOps оказалось довольно прямолинейной задачей. Вся магия сводится к двум вещам: аккуратно обращаться с приватным ключом и правильно собрать цепочку сертификатов. Если не лениться проверять себя через openssl перед перезагрузкой nginx, процедура получается надёжной и вполне повторяемой — как раз то, что нужно для боевого блога вроде krivoshein.site.
