5 ms·

It’s about damn time that we should be able to get intermediate signing certs that are domain limited from a public ca and issue out own “real” certs. This is f

It’s about damn time that we should be able to get intermediate signing certs that are domain limited from a public ca and issue out own “real” certs. This is fully supported in the standards. Anyone offering this product affordably yet?

diarrhea 3y ago
Interesting idea. What use cases would this make easier or even possible? At first, it sounds like more work (you’re now your own CA but without full freedom of a truly self hosted one).
- Nextgrid 3y ago
  The main advantage is that this CA and all downstream certificates would be globally-trusted (limited to the domain), which is not the case for a custom CA. Security-wise it shouldn't be any worse than wildcard certificates which are already a thing. It would actually improve things, because the user can now issue downstream certificates much more granularly without having to interact with the root CA (so you can issue fully offline for an intranet, or issue extremely-short-lived certificates that would otherwise run afoul of root CA's rate-limits).
  - jiggawatts 3y ago
    It would improve things for everybody but the certificate authorities. They're selling something with a marginal cost of zero for $50 each. A wildcard certificate costs more not because it is materially different or "harder" to issue, but because it replaces many $50 certificates. Thus, it "must" cost more, or everybody would just use wildcard certificates everywhere and reduce profits at the large public CAs. It is actually possible to get a domain-specific CA like the one you're thinking of. I saw one at a large department of education. It allowed unlimited issuance of certificates such as HTTPS, mail-signing, document-signing, and some other types that could be locked to a DNS domain. However, there was still a cost per certificate and the up-front cost was huge, something like $100K.
    - bombcar 3y ago
      Hopefully let’s encrypt continues to put the pressure on them so eventually the other cert authorities start offering things worth paying for.
    - nickf 3y ago
      I made a comment up-thread, but name-constrained CAs can issue for anything. It's enforced client-side, and not supported in far, far too many places to work. You'd be giving everyone the ability to issue for anything. Not to mention that running any kind of public CA is harder to do properly than most people thing. I get the negativity towards public CAs, but much of what you said isn't quite right, either.
      - Nextgrid 3y ago
        The only "safe" way to introduce these would be to make a certificate format that's intentionally incompatible with existing implementations; that way only new implementations (which are aware of the domain constraint) will accept it where as old implementations would just reject the certificate as invalid/corrupt.
    - yencabulator 3y ago
      LetsEncrypt already destroyed that "$50 ceremony for $0 cost" business model.
Dragging-Syrup 3y ago
The other “half” of the issue is getting the os, browsers, and devices to support the standard as well. That’s a whole other can of worms.
- 3np 3y ago
  Like gorkish wrote: No new standards or standard changes affecting any of those necessary. It's only a matter of will and culture on part of CAs.
  - michaelt 3y ago
    Name constraints are an optional feature in the standards. A client can ignore the constraints and be completely standards compliant. Should the CAs issue intermediate certs that are only secure if a client implements an optional feature? And even if most web browsers support name constraints properly - who knows if that cheap network webcam does, or that old mail client, or that 20 year old retro PC game?
    - 3np 3y ago
      So it may have limited use-cases today if you require full compat for all clients. For example internal controlled networks like discussed in the article. Just like you presumably already wouldn't issue LE certs when you need to support clients with ancient CA bundles. How do you think TLSv1.3 ever got rolled out?
    - wejn 3y ago
      This isn’t strictly true. If you want to uphold the name constraints in your CA cert, mark the field as critical. At that point clients that don’t understand them should fail validation of the CA cert.
c2h5oh 3y ago
Domain limiting is implemented using x.509 cert nameConstraints, which the last time I've checked were not supported on Apple devices.. Edit: has been fixed in osx 10.13.3. Idk about iOS.
- yencabulator 3y ago
  macOS 10.13.3 was released in January 2018, well over five years ago. Can we please stop repeating the "can't use it, it's not supported" line?

diarrhea 3y ago

Interesting idea. What use cases would this make easier or even possible? At first, it sounds like more work (you’re now your own CA but without full freedom of a truly self hosted one).

Nextgrid 3y ago
The main advantage is that this CA and all downstream certificates would be globally-trusted (limited to the domain), which is not the case for a custom CA. Security-wise it shouldn't be any worse than wildcard certificates which are already a thing. It would actually improve things, because the user can now issue downstream certificates much more granularly without having to interact with the root CA (so you can issue fully offline for an intranet, or issue extremely-short-lived certificates that would otherwise run afoul of root CA's rate-limits).
- jiggawatts 3y ago
  It would improve things for everybody but the certificate authorities. They're selling something with a marginal cost of zero for $50 each. A wildcard certificate costs more not because it is materially different or "harder" to issue, but because it replaces many $50 certificates. Thus, it "must" cost more, or everybody would just use wildcard certificates everywhere and reduce profits at the large public CAs. It is actually possible to get a domain-specific CA like the one you're thinking of. I saw one at a large department of education. It allowed unlimited issuance of certificates such as HTTPS, mail-signing, document-signing, and some other types that could be locked to a DNS domain. However, there was still a cost per certificate and the up-front cost was huge, something like $100K.
  - bombcar 3y ago
    Hopefully let’s encrypt continues to put the pressure on them so eventually the other cert authorities start offering things worth paying for.
  - nickf 3y ago
    I made a comment up-thread, but name-constrained CAs can issue for anything. It's enforced client-side, and not supported in far, far too many places to work. You'd be giving everyone the ability to issue for anything. Not to mention that running any kind of public CA is harder to do properly than most people thing. I get the negativity towards public CAs, but much of what you said isn't quite right, either.
    - Nextgrid 3y ago
      The only "safe" way to introduce these would be to make a certificate format that's intentionally incompatible with existing implementations; that way only new implementations (which are aware of the domain constraint) will accept it where as old implementations would just reject the certificate as invalid/corrupt.
  - yencabulator 3y ago
    LetsEncrypt already destroyed that "$50 ceremony for $0 cost" business model.

Dragging-Syrup 3y ago

The other “half” of the issue is getting the os, browsers, and devices to support the standard as well. That’s a whole other can of worms.

3np 3y ago
Like gorkish wrote: No new standards or standard changes affecting any of those necessary. It's only a matter of will and culture on part of CAs.
- michaelt 3y ago
  Name constraints are an optional feature in the standards. A client can ignore the constraints and be completely standards compliant. Should the CAs issue intermediate certs that are only secure if a client implements an optional feature? And even if most web browsers support name constraints properly - who knows if that cheap network webcam does, or that old mail client, or that 20 year old retro PC game?
  - 3np 3y ago
    So it may have limited use-cases today if you require full compat for all clients. For example internal controlled networks like discussed in the article. Just like you presumably already wouldn't issue LE certs when you need to support clients with ancient CA bundles. How do you think TLSv1.3 ever got rolled out?
  - wejn 3y ago
    This isn’t strictly true. If you want to uphold the name constraints in your CA cert, mark the field as critical. At that point clients that don’t understand them should fail validation of the CA cert.

c2h5oh 3y ago

Domain limiting is implemented using x.509 cert nameConstraints, which the last time I've checked were not supported on Apple devices.. Edit: has been fixed in osx 10.13.3. Idk about iOS.

yencabulator 3y ago
macOS 10.13.3 was released in January 2018, well over five years ago. Can we please stop repeating the "can't use it, it's not supported" line?