Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Incubator Q&A

Welcome to the staging ground for new communities! Each proposal has a description in the "Descriptions" category and a body of questions and answers in "Incubator Q&A". You can ask questions (and get answers, we hope!) right away, and start new proposals.

Comments on How to mitigate the risk of self-signed root CA?

Post

How to mitigate the risk of self-signed root CA? Question

+2
−0

Since self-signed server certs are discouraged nowadays, often people create their own root CA and sign server certs with that.

Obviously client apps won't trust the root CA, so the admin must then ask all users to install the root CA on their computer. With this, server certs signed by the root CA become accepted as valid.

However, this also introduces a security problem: With the root CA, the admin obtains a vector to MITM any site, like google.com. Often, the admin's goal is to simply provide secure TLS to their own server, and not to participate the security of connections to every site.

This is such a big trust requirement that even the admin himself might be concerned. You obviously wouldn't MITM yourself, but now the danger of leaking your CA's private key goes from "they can MITM a handful of servers I run" to "they can MITM any server".

Is there a way to get around this by restricting domains your own CA can issue certs for? This way, if you tried to sign a cert for google.com with this CA, the browser (and other apps) would reject it because google.com is not in the list of domains this CA is allowed to issue certs for.

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

This must be possible (3 comments)
This must be possible
Michael‭ wrote 3 months ago

The CA/B forum which approves (or denies) root CAs for the major browsers grants some CAs only limited domains, usually ccTLD, to issue valid certificates for. Perhaps examine a CA for (eg) the Turkish government or something? I don't know how to get openssl commands to mint a CA with those limitations, but it must be possible.

matthewsnyder‭ wrote 3 months ago

With gnutls, there is a nc_permit_dns key which seems to do this. I can't find specific docs but https://www.gnutls.org/manual/html_node/certtool-Invocation.html mentions it. IIRC when I tried to use it for a root CA, I got an error that root CAs cannot be restricted with that field. But it seems to be allowed for an intermediate CA. So I came up with the solution of:

  1. Self signed root CA
  2. Intermediate CA signed by root, but restricted to domains
  3. Server cert signed by intermediate CA

And then users are expected to install the intermediate CA, not the root CA, which seems to mitigate it. But I keep getting TLS errors anyway with this, so presumably I'm failing to pull this off properly.

I wonder if the Turkish CA is actually an intermediate CA, or if there's some way to restrict a root CA's domain range after all.

Michael‭ wrote 3 months ago

I found a guy on ServerFault who thinks he knows how to do it.