5 ms·

What I'd want is an internal CA, like step-ca, but have the certificates signed by a "real" CA, so I don't have to distribute my own root CA certificate.

filleokus 5y ago
The dream would truly be an internal CA backed by a publicly trusted subordinate cert (limited to the domain you control). But afaik that can’t happen until the Name Constraint Extension is enforced by “all” clients.
- deleted 5y ago
  [deleted]
- throw0101a 5y ago
  > But afaik that can’t happen until the Name Constraint Extension is enforced by “all” clients. For those curious about this extension, see RFC 5280 § 4.2.1.10: * https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10 https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10
corobo 5y ago
Wouldn't that allow you to issue certificates for Google.com? Correct me if I've misunderstood but for the sake of discussion pretend cert pinning doesn't exist, use another example domain if it's easier
- mrweasel 5y ago
  I'm not a 100% sure how certificates work. What I imagined would be possible is having a certificate for mydomain.com, which can be used to sign certificates for subdomains.
  - mmalone 5y ago
    You can put "name constraints" on an intermediate that, in theory, can restrict the intermediate to only signing certs for a particular subdomain. In theory, name-constrained intermediate certificate for `.example.com` would have no more authority than a wildcard certificate for `.example.com`. But, name constraints are enforced by "relying parties" -- HTTPS/TLS clients & servers that are validating certificates and authenticating remote peers. In practice, there's a risk that a broken/misconfigured relying party would trust a cert for google.com signed by an intermediate that's name constrained / only trusted to issue for `*.example.com`.
dsr_ 5y ago
That would be a violation of the real CA's duty to only sign certs that they have some basis for believing are correct. (This basis almost always boils down to "controls the DNS".)
meepmorp 5y ago
Yeah, that is the major drawback.
dnautics 5y ago
Out of curiosity, What's the problem with distributing your own root CAs? Is it security? Or is it "just a PITA"?
- Hamuko 5y ago
  Mostly the second.
runjake 5y ago
This would be called an "Intermediate CA" to those for whom this is unclear.
nym375 5y ago
You really don't actually want this. This intermediate CA would still be subject to the same extensive CAB Forum / vendor root program requirements (audited yearly via WebTrust) as a root CA. There are a ton of requirements, including mandatory response times, that inevitably makes this require a fully staffed team to operate.

filleokus 5y ago

The dream would truly be an internal CA backed by a publicly trusted subordinate cert (limited to the domain you control). But afaik that can’t happen until the Name Constraint Extension is enforced by “all” clients.

deleted 5y ago
[deleted]
throw0101a 5y ago
> But afaik that can’t happen until the Name Constraint Extension is enforced by “all” clients. For those curious about this extension, see RFC 5280 § 4.2.1.10: * https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10 https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10

corobo 5y ago

Wouldn't that allow you to issue certificates for Google.com? Correct me if I've misunderstood but for the sake of discussion pretend cert pinning doesn't exist, use another example domain if it's easier

mrweasel 5y ago
I'm not a 100% sure how certificates work. What I imagined would be possible is having a certificate for mydomain.com, which can be used to sign certificates for subdomains.
- mmalone 5y ago
  You can put "name constraints" on an intermediate that, in theory, can restrict the intermediate to only signing certs for a particular subdomain. In theory, name-constrained intermediate certificate for `.example.com` would have no more authority than a wildcard certificate for `.example.com`. But, name constraints are enforced by "relying parties" -- HTTPS/TLS clients & servers that are validating certificates and authenticating remote peers. In practice, there's a risk that a broken/misconfigured relying party would trust a cert for google.com signed by an intermediate that's name constrained / only trusted to issue for `*.example.com`.

dsr_ 5y ago

That would be a violation of the real CA's duty to only sign certs that they have some basis for believing are correct. (This basis almost always boils down to "controls the DNS".)

meepmorp 5y ago

Yeah, that is the major drawback.

dnautics 5y ago

Out of curiosity, What's the problem with distributing your own root CAs? Is it security? Or is it "just a PITA"?

Hamuko 5y ago
Mostly the second.

runjake 5y ago

This would be called an "Intermediate CA" to those for whom this is unclear.

nym375 5y ago

You really don't actually want this. This intermediate CA would still be subject to the same extensive CAB Forum / vendor root program requirements (audited yearly via WebTrust) as a root CA. There are a ton of requirements, including mandatory response times, that inevitably makes this require a fully staffed team to operate.