ServerAvatar и SSL сертификат за default server page

ServerAvatar е облачен инструмент за администриране на web и PHP application сървъри, който залага на опростен интерфейс, чрез който ефективно да се управляват базовите задачи: създаване на web сайт (засега се поддържат Apache и Nginx) и в частност вдигане на WordPress инсталация; създаване на база данни; Redis кеширане; издаване/преиздаване/подновяване на SSL сертификати и ръчно/автоматично архивиране локално или към външна услуга (AWS S3, Dropbox, Google Drive, Wasabi).

Самите сървъри могат да бъдат bare metal или виртуални машини, като единственото изискване е върху тях да бъде инсталиран начисто стандартен Ubuntu Linux Server, версия 16.04, 18.04 или 20.04. Поддържа се API интеграция с DigitalOcean, Vultr, AWS и Google Cloud за вдигане на виртуални машини от шаблон.

Най-важното на всичко това е, че не са необходими задълбочени познания по администрация на тези машини, понеже всички изброени по-горе операции са достъпни през прост и лесен за използване интерфейс. Тоест, ServerAvatar дава много добро начало на онези, които искат да се научат да създават и управляват web и php приложения, а на опитните администратори се пести време в извършването на досадни повтарящи се задачи. За мен лично, вдигането на WordPress макети на сайтове за тестове или разработки е най-лесно и бързо именно чрез ServerAvatar.

Услугата на ServerAvatar има достатъчно качества, че да си заслужи цялостно представяне в блога, и присъствието на настоящата статия цели да ме мотивира да го направя 🙂 но освен другото, блог секцията на сайта ми служи и за нещо като бележник, в който си записвам решенията на малки, но дразнещи проблеми, с които се сблъсквам — както стана и днес.

Конкретният проблем, на който трябваше да намеря решение, касае стандартната web страница, която се зарежда при отваряне по IP или адрес на самия сървър, управляван от ServerAvatar. Оказва се, че тази страница не получава автоматично собствен SSL сертификат, а вместо него услугата генерира дългосрочен self-signed сертификат. Това е неприемливо за мен по две причини:

1. Ако отварям сървъра по IP адрес, винаги ще получавам оплакване от браузера, че сертификатът е „несигурен“, понеже не е подписан от доверен издател.
2. Не мога да отварям сървъра по FQDN име, понеже имам активна HSTS политика за целия домейн, която не позволява на повечето съвременни браузери да отварят сайтове с невалиден или липсващ сертификат.

В този момент някои от моите читатели вероятно ще си отбележат наум, че отварянето на default страницата на машина, която хоства сайтове и/или приложения е до голяма степен безсмислено. И това наистина е така, но само донякъде. Повечето хостинг машини са настроени да показват страница тип „You’re not supposed to be here“, когато някой случайно или по погрешка опита да ги отвори, понеже обичайно зареждането на тази страница е индикатор за някаква грешка в настройките.

Но това не го прави правилното решение! Default страницата би могла да служи като визитка на бизнеса, да рекламира предлаганите услуги, да предлага помощ и насоки при технически проблеми и т.н. В моя конкретен случай, default страницата на всеки сървър под мой контрол се ползва за uptime monitoring. По този начин се диагностицират много по-лесно проблеми на ниво сървър (неработеща машина, изгубена свързаност…) и се разграничават от проблемите с конкретно web или php приложение, което върви върху този сървър.

Понеже ServerAvatar не ми дава възможност да генерирам автоматично сертификат за този vhost, трябваше да да поработя малко в конзолата.

Най-напред трябваше да разбера как се зарежда тази страница. За целта влязох в /etc/apache2/sites-enabled и се поогледах. ServerAvatar беше създал няколко vhost-а там: един за въпросната страница (000-default.conf и огледалната му конфигурация 000-default-ssl.conf), втора двойка за локалната phpMyAdmin инсталация, и още един vhost за WordPress приложението, което бях вдигнал на тази машина:

Бърз преглед на 000-default-ssl.conf показва, че ServerAvatar съхранява самоподписаните сертификати в /etc/ssl/certs, а техните частни ключове в /etc/ssk/private. Дотук — добре. Сега остава само лесното: да генерираме нов сертификат от LetsEncrypt с командата certbot certonly

Certbot интеграцията в Ubuntu е много удобна. Необходимо е единствено да въведете името на хоста, за който искате да издадете сертификат, и скриптът се грижи за всичко останало:

В случая и трите възможности ще свършат работа, но аз по навик избрах 1. След това въведох FQDN името на сървъра и оставих certbot да си говори с ACME CA за издаването на моя сертификат 🙂

Готовите сертификати на LetsEncrypt се съхраняват в поддиректории на /etc/letsencrypt/archive, като към най-новите им версии сочат символни връзки от /etc/letsencrypt/live/ за всеки сайт/приложение. Имате на разположение четири файла: cert.pem (сертификатът на сайта), chain.pem (междинната удостоверителна верига, която води от trust anchor-а до сертификата на сайта), fullchain.pem (удостоверителната верига и сертификата на едно място) и privkey.pem (частният ключ за този сертификат).

Единственото, което остана, е да редактирам 000-default-ssl.conf и да заместя файловете:

SSLEngine on
- SSLCertificateFile /etc/ssl/certs/sadefault.crt
- SSLCertificateKeyFile /etc/ssl/private/sadefault.key
+ SSLCertificateFile /etc/letsencrypt/live/xxx.example.com/fullchain.pem
+ SSLCertificateKeyFile /etc/letsencrypt/live/xxx.example.com/privkey.pem

и да презаредя vhost конфигурацията чрез service apache2 reload.

Какво постигнахме в крайна сметка? Няколко важни неща 🙂

1. Вече мога да следя целия сървър през uptime monitor-а (дали отговаря на
2. Мога да следя дали default страницата се зарежда и с каква скорост
3. Мога да съпоставям тези данни с поведението на приложенията, които се изпълняват върху същия сървър (ако default страницата се зарежда бързо, а дадено web/php приложение се бави, проблемът вероятно не е в сървъра и мрежовата свързаност)
4. Мога да следя за валидността на SSL сертификата на default страницата. Ако сертификатът изтече, това ще бъде индикатор, че автоматичното подновяване не работи — и е възможно да ме предупреди за потенциален проблем преди да изтече сертификатът на някое друго приложение, което е далеч по-важно.
5. Мога спокойно да поставя информативна страница, която да обяснява на посетителите как са стигнали дотук и какви мерки да предприемат.
6. Мога да си рекламирам специализираната хостинг услуга за онлайн магазини 🙂