.app ва .dev доменлар: нега уларда HTTPS мажбурий ва сайтни қандай тўғри созлаш керак

.app ва .dev доменлари дастурчилар ва мобил илова яратувчилар орасида жуда машҳур. Лекин уларни сотиб олган кўпчилик бир кутилмаган ҳолатга дуч келади: сайт файллари серверга юкланган, DNS тўғри созланган, аммо браузер сайтни очмайди ва хавфсиз уланиш хатосини кўрсатади. Бунинг сабаби бу зоналарнинг ўзига хос қоидасида: уларда шифрланмаган HTTP орқали ишлаш умуман имконсиз. Ушбу мақолада бу чеклов қандай ишлашини, ундан қандай фойда борлигини ва сайтни биринчи кундан тўғри ишга тушириш учун нима қилиш кераклигини кўриб чиқамиз.

HSTS ва preload рўйхати қандай ишлайди

HSTS (HTTP Strict Transport Security) бу браузерга "бу сайт билан фақат HTTPS орқали боғлан" деган кўрсатма берувчи механизм. Оддий ҳолатда сайт бу кўрсатмани жавоб сарлавҳасида юборади ва браузер уни биринчи муваффақиятли ташрифдан кейин эслаб қолади. Муаммо шундаки, энг биринчи ташриф ҳали ҳимояланмаган бўлади. Шу бўшлиқни ёпиш учун браузерлар preload деб аталадиган рўйхатни ўз ичига олади: рўйхатдаги доменлар учун HTTPS қоидаси браузерга олдиндан ёзилган бўлади ва биринчи уланишдан бошлаб амал қилади.

.app ва .dev зоналарини бошқарувчи реестр бу зоналарни бутунлигича preload рўйхатига киритган. Натижада Chrome, Firefox, Safari ва Edge каби замонавий браузерлар misol.dev ёки misol.app манзилига ҳеч қачон оддий HTTP орқали мурожаат қилмайди. Фойдаланувчи манзил сатрига http:// деб ёзса ҳам, браузер сўровни серверга юбормасдан олдин ўзи https:// га алмаштиради. Бу қоида зона ичидаги барча субдоменларга ҳам тегишли, масалан api.misol.dev ёки staging.misol.dev учун ҳам.

Сертификат бўлмаса нима бўлади

Оддий .uz ёки .com сайтида SSL сертификат муддати ўтса ёки нотўғри созланса, браузер огоҳлантириш кўрсатади, лекин баъзан "барибир давом этиш" тугмасини таклиф қилади. HSTS остидаги доменларда бундай имконият йўқ: сертификат яроқсиз бўлса, фойдаланувчи саҳифани оча олмайди. Шу сабабли .app ёки .dev сайтида сертификатни ўз вақтида янгилаб туриш оддий қулайлик эмас, сайтнинг ишлаши учун ҳаётий шарт.

Худди шу қоида аралаш контентга ҳам таъсир қилади. Саҳифа HTTPS орқали очилиб, ичидаги расм ёки скрипт http:// манзилдан юкланса, браузер бундай ресурсларни блоклаши мумкин. Шунинг учун сайтдаги барча ҳаволалар, CSS ва JavaScript файллари ҳам HTTPS орқали ёки нисбий йўл билан уланиши керак. WordPress каби тизимларда созламалардаги сайт манзили https:// билан бошланишини текшириб қўйиш фойдали.

Серверни тўғри созлаш

Агар сайт shared хостингда жойлашган бўлса, энг осон йўл панел орқали бепул Let's Encrypt сертификатини чиқариш ва автоматик янгиланишини ёқишдир. sayt.uz хостингида бу сертификат бепул берилади ва ўзи янгиланиб туради, шунинг учун .dev ёки .app доменини улагандан кейин биринчи навбатда SSL ҳолатини текшириш кифоя. Ўз VPS серверингизда эса сертификатни Certbot орқали олиш мумкин. Let's Encrypt домен эгалигини 80-порт орқали текширса ҳам, бу текширув браузер орқали эмас, сервер даражасида бўлади, шунинг учун HSTS унга халақит бермайди.

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

Nginx созламасида 80-портни бутунлай ўчириб қўйиш шарт эмас. Уни сақлаб, барча сўровларни HTTPS га 301 йўналтириш билан қайтариш тавсия қилинади: бу Let's Encrypt текширувлари ва HSTS ни қўлламайдиган эски мижозлар учун қулай. Қуйида misol.dev учун оддий намунавий конфигурация келтирилган.

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;
}

Зона даражасида HSTS аллақачон ёқилган бўлгани учун Strict-Transport-Security сарлавҳасини қўшиш мажбурий эмас, лекин уни қўшиш зарар қилмайди. Созламадан кейин сертификат ҳақиқатан тўғри берилганини ва муддатини қуйидаги буйруқлар билан текшириш мумкин. Эътибор беринг, curl браузерларнинг preload рўйхатидан фойдаланмайди, шунинг учун у билан http:// манзил ҳам очилиши мумкин, браузер эса буни ҳеч қачон қилмайди.

# 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

Субдоменларни унутманг

Кўп учрайдиган хато бу асосий домен учун сертификат олиб, субдоменларни унутишдир. Масалан, Самарқанддаги кичик IT жамоа мижозлар учун misol.app саҳифасини ишга туширди, кейин тест учун beta.misol.app субдоменини DNS'га қўшди, лекин унга сертификат чиқармади. Натижада тест топшириқни очмоқчи бўлган мижоз фақат хато ойнасини кўрди. Ҳар бир янги субдомен учун алоҳида сертификат чиқариш ёки DNS орқали тасдиқланадиган wildcard сертификат олиш бу муаммони ҳал қилади.

Локал ишлаб чиқишда .dev ишлатманг

Бир пайтлар дастурчилар ўз компьютерида лойиҳаларни misol.dev каби сохта номлар билан очишни яхши кўришарди. .dev ҳақиқий зона бўлиб, preload рўйхатига киргач, бундай локал манзиллар браузерда HTTPS талаб қила бошлади ва кўп ишлаб чиқиш муҳитлари бузилди. Локал лойиҳалар учун махсус ажратилган .test ёки .localhost номларидан фойдаланган тўғри. Улар ҳеч қачон интернетда ҳақиқий домен сифатида рўйхатдан ўтказилмайди ва браузерлар уларга HTTPS мажбурламайди.

127.0.0.1   misol.test
127.0.0.1   api.misol.test

Умуман олганда, .app ва .dev зоналаридаги мажбурий HTTPS бу чекловдан кўра ҳимоя. У фойдаланувчини очиқ Wi-Fi тармоқларида трафикни ўғирлаш ёки саҳифага бегона код қўшишдан сақлайди. Фақат битта қоидага амал қилиш керак: сайтни очишдан олдин сертификат тайёр бўлсин ва у автоматик янгиланиб турсин. Шунда .app ёки .dev домени бошқа ҳар қандай домен каби муаммосиз ишлайди.