.app va .dev domenlar: nega ularda HTTPS majburiy va saytni qanday to'g'ri sozlash kerak

.app va .dev domenlari dasturchilar va mobil ilova yaratuvchilar orasida juda mashhur. Lekin ularni sotib olgan ko'pchilik bir kutilmagan holatga duch keladi: sayt fayllari serverga yuklangan, DNS to'g'ri sozlangan, ammo brauzer saytni ochmaydi va xavfsiz ulanish xatosini ko'rsatadi. Buning sababi bu zonalarning o'ziga xos qoidasida: ularda shifrlanmagan HTTP orqali ishlash umuman imkonsiz. Ushbu maqolada bu cheklov qanday ishlashini, undan qanday foyda borligini va saytni birinchi kundan to'g'ri ishga tushirish uchun nima qilish kerakligini ko'rib chiqamiz.

HSTS va preload ro'yxati qanday ishlaydi

HSTS (HTTP Strict Transport Security) bu brauzerga "bu sayt bilan faqat HTTPS orqali bog'lan" degan ko'rsatma beruvchi mexanizm. Oddiy holatda sayt bu ko'rsatmani javob sarlavhasida yuboradi va brauzer uni birinchi muvaffaqiyatli tashrifdan keyin eslab qoladi. Muammo shundaki, eng birinchi tashrif hali himoyalanmagan bo'ladi. Shu bo'shliqni yopish uchun brauzerlar preload deb ataladigan ro'yxatni o'z ichiga oladi: ro'yxatdagi domenlar uchun HTTPS qoidasi brauzerga oldindan yozilgan bo'ladi va birinchi ulanishdan boshlab amal qiladi.

.app va .dev zonalarini boshqaruvchi reyestr bu zonalarni butunligicha preload ro'yxatiga kiritgan. Natijada Chrome, Firefox, Safari va Edge kabi zamonaviy brauzerlar misol.dev yoki misol.app manziliga hech qachon oddiy HTTP orqali murojaat qilmaydi. Foydalanuvchi manzil satriga http:// deb yozsa ham, brauzer so'rovni serverga yubormasdan oldin o'zi https:// ga almashtiradi. Bu qoida zona ichidagi barcha subdomenlarga ham tegishli, masalan api.misol.dev yoki staging.misol.dev uchun ham.

Sertifikat bo'lmasa nima bo'ladi

Oddiy .uz yoki .com saytida SSL sertifikat muddati o'tsa yoki noto'g'ri sozlansa, brauzer ogohlantirish ko'rsatadi, lekin ba'zan "baribir davom etish" tugmasini taklif qiladi. HSTS ostidagi domenlarda bunday imkoniyat yo'q: sertifikat yaroqsiz bo'lsa, foydalanuvchi sahifani ocha olmaydi. Shu sababli .app yoki .dev saytida sertifikatni o'z vaqtida yangilab turish oddiy qulaylik emas, saytning ishlashi uchun hayotiy shart.

Xuddi shu qoida aralash kontentga ham ta'sir qiladi. Sahifa HTTPS orqali ochilib, ichidagi rasm yoki skript http:// manzildan yuklansa, brauzer bunday resurslarni bloklashi mumkin. Shuning uchun saytdagi barcha havolalar, CSS va JavaScript fayllari ham HTTPS orqali yoki nisbiy yo'l bilan ulanishi kerak. WordPress kabi tizimlarda sozlamalardagi sayt manzili https:// bilan boshlanishini tekshirib qo'yish foydali.

Serverni to'g'ri sozlash

Agar sayt shared hostingda joylashgan bo'lsa, eng oson yo'l panel orqali bepul Let's Encrypt sertifikatini chiqarish va avtomatik yangilanishini yoqishdir. sayt.uz hostingida bu sertifikat bepul beriladi va o'zi yangilanib turadi, shuning uchun .dev yoki .app domenini ulagandan keyin birinchi navbatda SSL holatini tekshirish kifoya. O'z VPS serveringizda esa sertifikatni Certbot orqali olish mumkin. Let's Encrypt domen egaligini 80-port orqali tekshirsa ham, bu tekshiruv brauzer orqali emas, server darajasida bo'ladi, shuning uchun HSTS unga xalaqit bermaydi.

sudo certbot --nginx -d misol.dev -d www.misol.dev
sudo certbot renew --dry-run

Nginx sozlamasida 80-portni butunlay o'chirib qo'yish shart emas. Uni saqlab, barcha so'rovlarni HTTPS ga 301 yo'naltirish bilan qaytarish tavsiya qilinadi: bu Let's Encrypt tekshiruvlari va HSTS ni qo'llamaydigan eski mijozlar uchun qulay. Quyida misol.dev uchun oddiy namunaviy konfiguratsiya keltirilgan.

server {
    listen 80;
    server_name misol.dev www.misol.dev;
    return 301 https://misol.dev$request_uri;
}

server {
    listen 443 ssl;
    server_name misol.dev www.misol.dev;

    ssl_certificate     /etc/letsencrypt/live/misol.dev/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/misol.dev/privkey.pem;

    root /var/www/misol.dev;
    index index.html;
}

Zona darajasida HSTS allaqachon yoqilgan bo'lgani uchun Strict-Transport-Security sarlavhasini qo'shish majburiy emas, lekin uni qo'shish zarar qilmaydi. Sozlamadan keyin sertifikat haqiqatan to'g'ri berilganini va muddatini quyidagi buyruqlar bilan tekshirish mumkin. E'tibor bering, curl brauzerlarning preload ro'yxatidan foydalanmaydi, shuning uchun u bilan http:// manzil ham ochilishi mumkin, brauzer esa buni hech qachon qilmaydi.

# sertifikat kimga va qaysi muddatga berilganini ko'rish
openssl s_client -connect misol.dev:443 -servername misol.dev </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates

# HTTPS javobini tekshirish
curl -sI https://misol.dev | head -n 5

Subdomenlarni unutmang

Ko'p uchraydigan xato bu asosiy domen uchun sertifikat olib, subdomenlarni unutishdir. Masalan, Samarqanddagi kichik IT jamoa mijozlar uchun misol.app sahifasini ishga tushirdi, keyin test uchun beta.misol.app subdomenini DNS'ga qo'shdi, lekin unga sertifikat chiqarmadi. Natijada test topshiriqni ochmoqchi bo'lgan mijoz faqat xato oynasini ko'rdi. Har bir yangi subdomen uchun alohida sertifikat chiqarish yoki DNS orqali tasdiqlanadigan wildcard sertifikat olish bu muammoni hal qiladi.

Lokal ishlab chiqishda .dev ishlatmang

Bir paytlar dasturchilar o'z kompyuterida loyihalarni misol.dev kabi soxta nomlar bilan ochishni yaxshi ko'rishardi. .dev haqiqiy zona bo'lib, preload ro'yxatiga kirgach, bunday lokal manzillar brauzerda HTTPS talab qila boshladi va ko'p ishlab chiqish muhitlari buzildi. Lokal loyihalar uchun maxsus ajratilgan .test yoki .localhost nomlaridan foydalangan to'g'ri. Ular hech qachon internetda haqiqiy domen sifatida ro'yxatdan o'tkazilmaydi va brauzerlar ularga HTTPS majburlamaydi.

127.0.0.1   misol.test
127.0.0.1   api.misol.test

Umuman olganda, .app va .dev zonalaridagi majburiy HTTPS bu cheklovdan ko'ra himoya. U foydalanuvchini ochiq Wi-Fi tarmoqlarida trafikni o'g'irlash yoki sahifaga begona kod qo'shishdan saqlaydi. Faqat bitta qoidaga amal qilish kerak: saytni ochishdan oldin sertifikat tayyor bo'lsin va u avtomatik yangilanib tursin. Shunda .app yoki .dev domeni boshqa har qanday domen kabi muammosiz ishlaydi.