# Custom Domains and HTTPS Support in WordPress Studio > [!question] Lingering Questions > - How does Studio scope and rotate its generated root CA for local HTTPS — a security-hygiene question the video skips. > - What's the documented Windows cert-install flow? The video only shows macOS. > [!tip] Article Ideas > - n/a — a focused feature tutorial; the reusable idea (local should mirror production protocol) is captured as a Permanent note. > [!link] Cross Reference > - [[3. Resources/Literature Notes/An introduction to WordPress Studio]] — the same optional-HTTPS toggle mentioned briefly there ("handy for Jetpack"), covered in full here. > [!quote] Vocabulary > - **`.local` TLD** — the required suffix for a Studio custom domain; must also be unique across your Studio sites to avoid hosts-file/routing collisions. ## Metadata - Source: [[3. Resources/Readwise/Articles/Custom Domains and HTTPS Support in WordPress Studio]] - Author: WordPress.com (host: Nick) - Format: vendor feature tutorial (YouTube) - Date processed: 2026-08-16 ## Author's thesis Studio lets you assign a custom `.local` domain and enable HTTPS on a local site so that local development more closely resembles production's protocol and URL shape, catching secure-cookie and mixed-content issues before deploy instead of after. It matters because dev/prod parity on protocol is a real bug-prevention practice, not just cosmetic — but the video only documents the macOS trust-the-certificate flow and stays silent on cert lifecycle and Windows setup. ## Key arguments (≤3) 1. Local HTTPS exists specifically to make local sites resemble production more closely, catching protocol-dependent bugs early. 2. Custom domains are constrained: they must end in `.local` and must be unique across a user's Studio sites, or routing collisions follow. 3. The video documents only the macOS certificate-trust flow, leaving certificate scoping/rotation and the Windows path undocumented. ## Claim atoms ### Local HTTPS makes dev sites resemble production > [!quote] ID:rw_h1 > create sites with secure connections that more closely resemble production environments **Context & use**: ~00:00:55, the stated rationale for enabling HTTPS on local sites. Justifies HTTPS-by-default locally: matching production reduces environment drift and protocol-related surprises at deploy. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> ### Studio custom domains must end in .local > [!quote] ID:rw_h2 > it needs to end in local and also don't use it DOT local domain you've already set up **Context & use**: ~00:02:30, the caveat when choosing a custom domain for a new Studio site. Practical constraint: domain must use the `.local` TLD and be unique across Studio sites, or hosts-file/routing collisions occur. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> ## Permanent candidates - **Local environments should mirror production protocol** — supported directly by the local-HTTPS-rationale atom; promoted to [[3. Resources/Permanent Notes/Local Environments Should Mirror Production Protocol]]. ## Processing checklist - [ ] Check how Studio scopes/rotates its generated root CA for security hygiene - [ ] Find the documented Windows cert-install flow the video skips - [x] Connect into the relevant MOC — [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] ## Links - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — local HTTPS/TLS parity and root-CA generation are hosting-stack security-hygiene questions. - [[3. Resources/MOCs/WordPress Platform Design MOC]] — applies-in: Joins WordPress tooling notes; fit is loose.