All Projects → luisfarzati → Localdots

luisfarzati / Localdots

Licence: other
HTTPS domains for localhost. 🏠

Projects that are alternatives of or similar to Localdots

docker-nginx-certbot
Automatically create and renew website certificates for free using the Let's Encrypt certificate authority.
Stars: ✭ 367 (-24.49%)
Mutual labels:  https, acme, localhost, ssl-certificates
Certify
SSL Certificate Manager UI for Windows, powered by Let's Encrypt. Download from certifytheweb.com
Stars: ✭ 1,075 (+121.19%)
Mutual labels:  https, acme, ssl-certificates
Https Localhost
HTTPS server running on localhost
Stars: ✭ 122 (-74.9%)
Mutual labels:  https, local-development, localhost
Mkcert
A simple zero-config tool to make locally trusted development certificates with any names you'd like.
Stars: ✭ 33,022 (+6694.65%)
Mutual labels:  https, local-development, localhost
Forwardproxy
Forward proxy plugin for the Caddy web server
Stars: ✭ 333 (-31.48%)
Mutual labels:  proxy, https, caddy
acmed
ACME (RFC 8555) client daemon
Stars: ✭ 121 (-75.1%)
Mutual labels:  acme, ssl-certificates
portless
Easy local domains with superpowers
Stars: ✭ 106 (-78.19%)
Mutual labels:  https, localhost
ght-acme.sh
Shell script to sign certificate by the letsencrypt CA
Stars: ✭ 31 (-93.62%)
Mutual labels:  acme, ssl-certificates
Getaltname
Extract subdomains from SSL certificates in HTTPS sites.
Stars: ✭ 320 (-34.16%)
Mutual labels:  https, ssl-certificates
anvil
Tools for distributing ssl certificates
Stars: ✭ 29 (-94.03%)
Mutual labels:  acme, ssl-certificates
jota-cert-checker
Check SSL certificate expiration date of a list of sites.
Stars: ✭ 45 (-90.74%)
Mutual labels:  https, ssl-certificates
Certmagic
Automatic HTTPS for any Go program: fully-managed TLS certificate issuance and renewal
Stars: ✭ 3,864 (+695.06%)
Mutual labels:  https, acme
docker-mkcert
Docker container for creating valid local ssl certificates
Stars: ✭ 87 (-82.1%)
Mutual labels:  ssl-certificates, local-development
Ghost-over-Caddy
This repo/script will install Ghost blog over Caddy web server as a reverse proxy.
Stars: ✭ 20 (-95.88%)
Mutual labels:  https, caddy
cryptonice
CryptoNice is both a command line tool and library which provides the ability to scan and report on the configuration of SSL/TLS for your internet or internal facing web services. Built using the sslyze API and ssl, http-client and dns libraries, cryptonice collects data on a given domain and performs a series of tests to check TLS configuration…
Stars: ✭ 91 (-81.28%)
Mutual labels:  https, ssl-certificates
Crypt Le
Crypt::LE - Let's Encrypt / Buypass / ACME client and library in Perl for obtaining free SSL certificates (inc. generating RSA/ECC keys and CSRs). HTTP/DNS verification is supported out of the box, easily extended with plugins, easily dockerized.
Stars: ✭ 277 (-43%)
Mutual labels:  https, acme
Certes
A client implementation for the Automated Certificate Management Environment (ACME) protocol
Stars: ✭ 357 (-26.54%)
Mutual labels:  https, ssl-certificates
E2guardian
E2guardian is a web content filter that can work in proxy, transparent or icap server modes
Stars: ✭ 340 (-30.04%)
Mutual labels:  proxy, https
Nginx Le
Nginx with automatic let's encrypt (docker image)
Stars: ✭ 475 (-2.26%)
Mutual labels:  proxy, ssl-certificates
docker-ssl-reverse-proxy
Easy-to-use auto-SSL reverse proxy as a Docker container based on Caddy and Let’s Encrypt
Stars: ✭ 22 (-95.47%)
Mutual labels:  https, caddy

Docker Cloud Build Status

localdots — HTTPS domains for localhost

Inspired by https://smallstep.com/blog/step-v0-8-6-valid-https-certificates-for-dev-pre-prod/

Important/Disclaimer

⚠️ This tool installs a root CA in your system. Use it only if you know what you are doing.

Also Important

As the title says, this tool is to be used for development. It is not meant to run at production and it hasn't been tested in CI environments either.

Please help report any issues!

Features

localdots combines Caddy and smallstep/certificates with automated configuration and hot reload.

  • Generates SSL/TLS certificates automatically
  • Reloads Caddy automatically with every change

Usage

# docker-compose.yaml

version: "3"

services:
  proxy:
    image: rnbw/localdots
    ports:
      - 80:80 # for http->https redirection
      - 443:443
    volumes:
      # contains all vhost files
      - ./caddy.d:/caddy.d:ro
      # contains CA config and certs
      - ~/.caroot:/caroot
    # only needed for *.localhost domains
    extra_hosts:
      - "whoami.localhost:127.0.0.1"

  # example containers
  whoami:
    image: jwilder/whoami
  hello:
    image: nginxdemos/hello
# ./caddy.d/whoami.localhost
whoami.localhost {
  proxy / whoami:8000
}

# ./caddy.d/hello.dev
hello.dev {
  proxy / hello
}
# run all the things
docker-compose up -d

# add the domains to your /etc/hosts file
# *.localhost domains shouldn't need to be added for typical use cases
127.0.0.1  hello.dev

# after localdots container is up and running,
# you will see a .caroot directory in your $HOME.
brew install step \
    && step certificate install ~/.caroot/certs/root_ca.crt

# that's it, try open the sites configured above
open https://whoami.localhost
open https://hello.dev

About domains

Using special TLDs

When picking a TLD for local development, you can use one of the special domain names suggested in RFC6761, such as test or localhost.

localhost has, by spec, the following particularities:

1.  Users are free to use localhost names as they would any other
    domain names.  Users may assume that IPv4 and IPv6 address
    queries for localhost names will always resolve to the respective
    IP loopback address.

2.  Application software MAY recognize localhost names as special, or
    MAY pass them to name resolution APIs as they would for other
    domain names.

3.  Name resolution APIs and libraries SHOULD recognize localhost
    names as special and SHOULD always return the IP loopback address
    for address queries and negative responses for all other query
    types.  Name resolution APIs SHOULD NOT send queries for
    localhost names to their configured caching DNS server(s).

However, if you expect anything.localhost to be resolved to 127.0.0.1 automatically, that might not work. For example, you can open it in Chrome and the browser will resolve it fine. But if you ping it or curl it, you'll get an error unless you add the record in your hosts file.

See https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-06.

Using any TLD

Using any of the domains above, you can be sure you won't run into any conflicts. But other than that, there's no reason why you cannot use any other "registrable" domain. There are ~1600 possible TLDs you can choose from, or even invent your own!

While this can be seen as bad practice, I leave it to you. Personally I've seen several companies or dev teams using xyz, wtf, lol, dev, net, host, or even custom ones (i.e. not in the list) such as using the company name or team.

In my opinion, as long as you 1- know what you are doing, 2- don't shadow an existing domain that you or someone in your team uses (e.g. don't use gmail.com...) and 3- keep it scoped to your local development environment, then just use whatever works for you.

As with special domains, remember to add the necessary entries in your hosts file. Alternatively in this case, if you own the domain then you can always add the record in your DNS.

Contributing

Bugfixes, improvements, proposals are gladly welcome!

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].