[PR #309] Add DNS whitelist option to CA generation #438

New issue

Open

opened 2026-02-25 22:33:30 +03:00 by kerem · 0 comments

kerem commented

2026-02-25 22:33:30 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/FiloSottile/mkcert/pull/309
Author: @ivanbakel
Created: 11/18/2020
Status: 🔄 Open

Base: master ← Head: feature/dns-whitelisting

📝 Commits (1)

922158e Add DNS whitelist option to CA generation

📊 Changes

2 files changed (+21 additions, -0 deletions)

View changed files

📝 cert.go (+4 -0)
📝 main.go (+17 -0)

📄 Description

This uses the NameConstraints extension to allow for DNS whitelisting on the local CA when it is first generated.

I'm aware that you've rejected this kind of change before, but I want to clarify why this version is different, addressing those points:

This is totally opt-in, and it's not just on localhost. You can use this to produce a minimally-responsible CA for any set of domains, as normal.
This makes explicit in the option help that compliance with the whitelist is optional, and cannot be relied on for security purposes.
While I agree that being able to read the local private key and therefore forge certificates issued by the local CA is a big pwn, there are two benefits to restricting the local CA:
1. It allows for certainty that the CA itself has a minimal responsibility, and therefore that different CAs (used for different development purposes) do not overlap in their issuance in a way that would cause problems outside of testing/development.
2. If the user's stack does check NameConstraints, then by Swiss Cheese, it is simply an improvement to security in the unlikely case that a remote attacker tricks the user into issuing a certificate from their local CA. But of course, this is a very minor benefit.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/FiloSottile/mkcert/pull/309 **Author:** [@ivanbakel](https://github.com/ivanbakel) **Created:** 11/18/2020 **Status:** 🔄 Open **Base:** `master` ← **Head:** `feature/dns-whitelisting` --- ### 📝 Commits (1) - [`922158e`](https://github.com/FiloSottile/mkcert/commit/922158ed6856077c8b07478d67e0a7a930b90510) Add DNS whitelist option to CA generation ### 📊 Changes **2 files changed** (+21 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `cert.go` (+4 -0) 📝 `main.go` (+17 -0) </details> ### 📄 Description This uses the `NameConstraints` extension to allow for DNS whitelisting on the local CA when it is first generated. I'm aware that [you've rejected this kind of change before](https://github.com/FiloSottile/mkcert/pull/113#issuecomment-459999460), but I want to clarify why this version is different, addressing those points: * This is totally opt-in, and it's not just on `localhost`. You can use this to produce a minimally-responsible CA for any set of domains, as normal. * This makes explicit in the option help that compliance with the whitelist is optional, and cannot be relied on for security purposes. * While I agree that being able to read the local private key and therefore forge certificates issued by the local CA is a big pwn, there are two benefits to restricting the local CA: 1. It allows for certainty that the CA itself has a minimal responsibility, and therefore that different CAs (used for different development purposes) do not overlap in their issuance in a way that would cause problems outside of testing/development. 2. If the user's stack *does* check `NameConstraints`, then by Swiss Cheese, it is simply an improvement to security in the unlikely case that a remote attacker tricks the user into issuing a certificate from their local CA. But of course, this is a very minor benefit. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>