.app and .dev are popular with developers and mobile app makers, but many buyers hit a surprise: the files are uploaded, DNS is correct, and the browser still refuses to open the site with a secure connection error. The reason is a special rule of these zones: plain, unencrypted HTTP simply does not work. Here is how the rule works, why it helps, and how to launch a site correctly from day one.
How HSTS and the preload list work
HSTS (HTTP Strict Transport Security) tells a browser to talk to a site over HTTPS only. Normally the site sends this in a response header and the browser remembers it after the first successful visit, which leaves that first visit unprotected. Browsers close the gap with a preload list: for domains on it, the HTTPS rule is built in and applies from the very first connection. The registry behind .app and .dev put both zones on that list as a whole, so Chrome, Firefox, Safari and Edge never contact misol.dev or misol.app over HTTP. Even if a user types http://, the browser switches to https:// before sending anything, and the rule covers every subdomain such as api.misol.dev.
What happens without a certificate
On an ordinary .uz or .com site an expired or broken certificate triggers a warning that sometimes offers a "proceed anyway" button. Under HSTS there is no such option, so an invalid certificate means the page cannot be opened at all. Renewing on time is a hard requirement, not a nicety. Mixed content is affected too: images or scripts loaded from http:// URLs on an HTTPS page may be blocked, so use HTTPS or relative paths everywhere and make sure the site URL in a CMS such as WordPress starts with https://.
Configuring the server
On shared hosting the simplest route is a free Let's Encrypt certificate from the control panel with auto-renewal; on sayt.uz hosting it is free and renews itself, so after connecting a .dev or .app domain just check the SSL status first. On your own VPS use Certbot. Let's Encrypt validates over port 80, but that check is server-to-server, not a browser, so HSTS does not interfere.
sudo certbot --nginx -d misol.dev -d www.misol.dev
sudo certbot renew --dry-run
Keep port 80 open and answer every request with a 301 redirect to HTTPS; it helps Let's Encrypt checks and older clients. A minimal Nginx example for 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;
}
Because HSTS is already enforced for the whole zone, adding a Strict-Transport-Security header is optional but harmless. Verify the certificate and its dates with the commands below. Note that curl does not use the browser preload list, so it may still fetch an http:// URL, which a browser never will.
# who the certificate is issued to and its validity dates
openssl s_client -connect misol.dev:443 -servername misol.dev </dev/null 2>/dev/null \
| openssl x509 -noout -subject -dates
# check the HTTPS response
curl -sI https://misol.dev | head -n 5
Don't forget subdomains
A common mistake is securing the main domain and forgetting subdomains. A small IT team in Samarkand launched misol.app for clients, then added beta.misol.app in DNS for testing without issuing a certificate, and the client trying to review the build saw only an error screen. Issue a certificate for each new subdomain or use a wildcard certificate validated through DNS.
Don't use .dev for local development
Developers once liked fake local names such as misol.dev. Once .dev became a real, preloaded zone, those local addresses started demanding HTTPS and many setups broke. Use the reserved .test or .localhost names instead; they are never registered on the internet and browsers do not force HTTPS on them.
127.0.0.1 misol.test
127.0.0.1 api.misol.test
Mandatory HTTPS on .app and .dev is protection rather than a limitation: it shields users from traffic interception and code injection on open Wi-Fi. Just make sure the certificate is ready before launch and renews automatically, and the domain will work like any other.