FEATURES

HTTPS

Container names work over HTTPS too: https://web.kiri.local reaches the same container as http://web.kiri.local. Kiri makes the certificates itself, so you don’t run mkcert or edit your app’s TLS settings. Your app keeps serving plain HTTP inside the container.

Turn it on

HTTPS needs your Mac to trust Kiri’s certificate authority, once.

  1. Open Settings → Domains in Kiri’s window.

  2. Next to HTTPS, choose On.

  3. macOS asks for your password to change your trust settings. Kiri never sees it.

  4. Open https://<name>.kiri.local (or .kiri.localhost) in your browser.

Once it is on, the window’s links to containers open with https://.

Kiri
ContainersImagesVolumesNetworksSettings

Domains

Local names<name>.kiri.localkiri.localhostkiri.local
HTTPSonly .kiri.local and .kiri.localhostOffOn
Settings → Domains with HTTPS on. Off takes the trust back and removes the authority from your login keychain.

Kiri’s certificate authority

The first time it’s needed, Kiri makes its own certificate authority, the Kiri Local Certificate Authority, and keeps it in ~/.kiri/tls:

File What
ca.pem The authority’s certificate, the one macOS trusts.
ca-key.pem Its private key, readable by you only (the folder is 0700, the key 0600).
ca.version The authority’s format version.

Turning HTTPS on adds the certificate to your login keychain, where Keychain Access shows it, and marks it as a trusted root for websites, for your user only. It is not trusted for anything else, such as code signing or email.

It can only vouch for Kiri’s names

A trusted root can normally sign a certificate for any site, which makes its key valuable to steal. Kiri’s authority carries name constraints that limit it to names ending in .kiri.local or .kiri.localhost, and exclude every IP address. Browsers and macOS check these constraints, so even with the key, nobody could make a certificate your Mac would accept for your bank, or for https://192.168.1.1.

Your login keychaintrusted root, websites onlytrustsKiri Local Certificate Authority~/.kiri/tls/ca.pempermitted:*.kiri.local *.kiri.localhostexcluded:every IPv4 and IPv6 addresssigns, on first useweb.kiri.localone certificate per namevalid 390 days, renewed by Kiriexample.comoutside the constraints:rejected
The trust chain. macOS trusts Kiri's authority as a root for websites; the authority's name constraints limit what it can sign to Kiri's own names.

A certificate per name

Kiri doesn’t make one wildcard certificate. When a browser connects to port 443, it says which name it wants (SNI), and Kiri signs a certificate for exactly that name the first time it’s asked, then keeps it while the daemon runs. Compose names like api.shop.kiri.local and names from the dev.kiri.domain label get theirs the same way.

Each certificate is valid for 390 days, under the 825-day limit macOS sets for server certificates. Kiri makes a fresh one when the current one has 30 days left.

The path of a request

Kiri’s router ends TLS on your Mac. It decrypts the request, picks the container from the Host header as it does for plain HTTP, and relays the bytes into the VM to the container’s HTTP port. The container sees an ordinary HTTP request.

Your MacKiri’s VMBrowserweb.kiri.localKiri’s router :443cert for the SNI nameTLSSNIweb.kiri.localweb:80plain HTTPover vsock
HTTPS ends at Kiri's router on the Mac. The container gets plain HTTP on its own port, picked as for http:// names.

The router offers HTTP/1.1 over TLS. Only connections from this Mac are served.

Turn it off

Choose Off next to HTTPS. Kiri takes back the trust setting and deletes the authority’s certificate from your login keychain. The files in ~/.kiri/tls stay, so turning it on again trusts the same authority. Plain http:// names keep working either way.

Domain namesWhich names a container answers to, and which port Kiri uses.SecurityWhat Kiri can and can’t reach on your Mac.

© 2026 Kiri · runkiri.com