HTTPS on a Local Windows Host

Local HTTPS is not paranoia. Secure cookies, http to https redirects, payment return URLs, and Service Worker in some scenarios cannot be checked properly on plain http. In MicroServer, certificates are issued by a local CA; your task is to make the browser trust it.

This is not Let's Encrypt for a public domain. Public SSL on hosting has a separate manual.

What is needed

• A virtual host project.loc already opens over http: how to create it.
• The host is added to the server SSL list, including related settings in config/server.json.
• The root CA certificate is installed into Windows/browser trusted stores.
• Port 443 listens, and 80 redirects if needed.

Stack overview: local server.

Trusting the certificate

Without installing the root, Chrome/Edge show a warning. You can click through, but some API and cookie scenarios suffer. Install the MicroServer root certificate into Trusted Root Certification Authorities for the local machine.

Firefox sometimes uses its own store, so import it there separately if you test in Firefox.

Check

1. Open https://project.loc; the lock should appear without a name error.
2. Mixed content: source should not contain active http resources from the same host.
3. Log in to the admin panel; the session should survive page reload.
4. If the script forces redirect to https, set the URL with https in settings.

Typical problems

• Certificate for another name: the host was not included, or you opened www. or an IP.
• Warning after regenerating CA: old root in system, new server; update trust.
• Port 443 occupied by OpenServer/IIS; free it or stop the extra stack.
• HSTS from previous experiments on this name; rare, but annoying. Clear site state in the browser.

Why Microscript scripts need it

It helps check accounts and forms before deployment. Debugging payment callbacks locally through tunnels such as ngrok often requires https. Redirect behavior after enabling SSL on production is better seen locally once.

Product installation: installation. If https opens but PHP fails, the certificate is no longer the issue: 500 error.

Alternatives

A manually created self-signed certificate with openssl and Apache config works in XAMPP/OpenServer, but takes longer. mkcert is popular for arbitrary stacks. In MicroServer, the built-in CA is simpler.

About Denver and PHP 8: Denver replacement. When local setup is ready: deployment: migration, production SSL: site SSL.

Windows Firewall

For access only from this machine, rules on 443 usually do not matter. If you open the local host from a phone on the same Wi-Fi, that is a separate network and certificate-trust setup on the phone; it is not required for everyday script development.

Redirect from http to https locally

Enable it if you debug behavior similar to production. Otherwise some links in emails and templates may remain http and you will notice only after deployment. In MicroServer, redirect usually depends on the SSL-host list. If manual https works but automatic redirect does not, check that the host is in the list and the server was reloaded.

A redirect loop locally happens when the script forces https but the virtual host on 443 is not configured. Browser shows ERR_TOO_MANY_REDIRECTS. Disable forcing in script settings, fix the SSL host, then enable it again.

Cookies, sessions, SameSite

On local https, session cookies with Secure start saving. On http they did not, so "login does not persist" after switching protocols can look like a script bug. Clear cookies for project.loc and log in once over https.

If you test an embedded frame or a separate frontend on another port, SameSite and secure flags can interfere. That is more advanced debugging; a normal Microscript admin panel usually needs one host on 443.

Mixed content locally

Check blocked:mixed-content in the browser console. Absolute URLs in demo data or the "site address" setting with http are common causes. Change the admin URL to https://project.loc and clear cache. The same production story is covered in SSL on a PHP site.

Several browsers

Chrome/Edge use the Windows store. Firefox uses its own. If the root CA is installed in the system but Firefox still complains, import the certificate in Firefox settings too. Safari on another Mac has no relation to your Windows CA.

Incognito may not see manually installed roots as you expect, depending on browser policy. Check the lock in a normal window after installing the CA.

Port conflict

Skype, IIS, Docker, and OpenServer like to occupy 443. MicroServer cannot start https while the port is busy. In PowerShell:

netstat -ano | findstr :443

The PID tells you the process. Stop the extra stack. More about stack conflicts: Denver replacement.

Connection with installation and migration

Install the script on the same protocol you will use to debug the account area. Switching http to https after demo data is filled adds URL cleanup work. Installation: manual. The database is the same: phpMyAdmin.

When local https is debugged, issue a normal Let's Encrypt certificate in production; the local CA is not copied there. Migration: script migration. If production shows a white screen after SSL, read PHP logs, not the certificate: 500 error.

For external-service webhooks to local development, https alone is not enough; you need a tunnel with a public name. The tunnel certificate is separate, and your MicroServer CA is unrelated. Remember this so you do not fix "local SSL" when ngrok is failing.

If the lock is present but the script generates http links, fix "site URL" in the admin panel and clear product cache if it exists. Otherwise payment and redirect debugging remains misleading. Installation and initial setup: installation. The database does not migrate when only the protocol changes; files are the same. The host must be stable: *.loc. Stack: MicroServer.