7 ms·

I have custom root certs for internal dev sites for my company. That's fine, but I'd like to add the root with a caveat that I control saying "I trust this root

I have custom root certs for internal dev sites for my company. That's fine, but I'd like to add the root with a caveat that I control saying "I trust this root for *.mycompany.com,mycompany.org", but that I know means they wouldn't be able to proxy "mybank.com". I don't think Firefox or Chrome can do that can it?

vbezhenar 7y ago
Just issue self-signed certificate for *.mycompany.com, mycompany.org and then put it into trust store, without CA flag set.
schoen 7y ago
No, although the root itself could be scoped that way with an X.509 name constraint. But if you add the root then I believe there's no browser policy to otherwise limit the names for which it can be trusted.
- acdha 7y ago
  On a tangent, do you know off-hand what browser support for name constraints is like? The last time I looked was a few years ago and at the time it wasn't well supported but if that's improved it'd be a good step for intermediate certs.
  - jitbug 7y ago
    It must have been many many years ago, more than 10 at least. Any way to avoid or bypass name or path constraints would be considered a huge and monumental vulnerability today.
    - acdha 7y ago
      > It must have been many many years ago, more than 10 at least. You would be unduly optimistic — for example, Apple did not support them at least as recently as 2015 (see e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=407093#c2 https://bugs.chromium.org/p/chromium/issues/detail?id=407093...) and 10 years ago OpenSSL hadn't even shipped support upstream, plus however long it took your distribution to ship a major version upgrade to 1.0. I was hoping someone might have a pointer to current information on that topic since I believe Apple did finally fix Secure Transport but not when.
      - gnyman 7y ago
        I am afraid I don't have better information on when but some anecdotal information about the state of it. I have done some limited testing and research for our own internal Root CA I got the impression it works nowadays. I have not gotten as far as testing it in production but based on testing Safari and Chrome in https://nameconstraints.bettertls.com/ https://nameconstraints.bettertls.com/ and creating our own name constrained cert and testing it with both OS X Curl and Linux Curl (OpenSSL) I am still of the impression it works. Most other people seem to be sure that it does not though (for example in this discussion and here https://security.stackexchange.com/questions/95600/are-x-509-nameconstraints-on-certificates-supported-on-os-x https://security.stackexchange.com/questions/95600/are-x-509...) so I am not sure if I missed something or if people are just not up to date.
  - wiml 7y ago
    The last time I looked into it, a few years ago, everyone except Apple had some basic amount of support. (That is, openssl, firefox, windows, and android — that's all I looked into.) I set up my private CA with name constraints, but I had to mark them noncritical if I wanted iDevices to be able to use the CA at all. But the other systems did at least appear to honor the constraints. I've asked Apple security folks about this a few times, but they just look uncomfortable and change the topic.
- mdhardeman 7y ago
  Actually true root certs when evaluated by the browsers will have their name constrains within the root certificate themselves ignored. Modern browsers do respect name constraints of intermediate issuing certificates.
  - schoen 7y ago
    Thanks for the correction!
burtonator 7y ago
For root certain? But you can add your own self signed certs for domains an they can be wildcards. You only need a root if you're issuing other keys.
- deleted 7y ago
  [deleted]
y0ghur7_xxx 7y ago
There is a Name Constraints extension in X.509[1] that does exactly that, but to my knowledge no browser implements it. [1] https://tools.ietf.org/html/rfc5280#section-4.2.1.10 https://tools.ietf.org/html/rfc5280#section-4.2.1.10
- markovbot 7y ago
  and that would have to be baked into the CA certificate, not specified when the CA is trusted. I dont want my browser to ask the CA what it's allowed to do, i want to tell it what it's allowed to do
  - y0ghur7_xxx 7y ago
    It has to be baked into the CA, so that a browser vendor can check it before inclusion. If the CA specifies domains it is not allowed to sign certificates for, it will not be included.
- jack12 7y ago
  > but to my knowledge no browser implements it Firefox does, though I don't know how much they check beyond just the dNSName constraints. Here's the unit test making sure it stays working: https://github.com/mozilla/gecko-dev/blob/b8157dfaafc42deb3b9824ab6aab1c3e11636d76/security/manager/ssl/tests/unit/test_name_constraints.js https://github.com/mozilla/gecko-dev/blob/b8157dfaafc42deb3b...
JoshTriplett 7y ago
I'd like that as well, for exactly the same purpose. To the best of my knowledge, no browser can do this today, and I don't know of any other software that can do that either. (I'd want to have it in the system certificate store with the same constraint, as well.) Name Constraints, as mentioned elsewhere in this thread, wouldn't solve the problem, for two reasons: most software doesn't support them (and silently ignores them rather than correctly failing closed), and they require the CA certificate to contain the constraints rather than system configuration adding the constraints. We need a mechanism to place certificates in a certificate store (browser or system) with specific domain constraints configured by the administrator. To avoid the failure mode of Name Constraints, those certificates shouldn't be accessible to software that doesn't know to enforce domain constraints. That would also require updates to various SSL libraries (and to browsers) to handle this new certificate store and enforce the constraints.
- wiml 7y ago
  > most software doesn't support [name constraints] (and silently ignores them rather than correctly failing closed) Could you elaborate on this? Specific examples? CVEs? My experience has been that most software will either honor them, or honor the "critical" flag, which is correct (if disappointing) behavior. If you want it to fail closed, use the critical flag. If you want it to fail open, clear the critical flag.
  - JoshTriplett 7y ago
    The last time I investigated this this, several years ago, I found that several SSL libraries simply ignored the extension entirely, whether it had "critical" or not. Older OpenSSL did so, for instance. Doing some additional research, it looks like the situation has improved significantly now, and name constraints might actually work as designed if you don't care about older systems. That still doesn't address the ability for a browser/administrator to apply such name constraints to a CA that didn't ship as part of its certificate, though.
- jasonh3 7y ago
  A mechanism to constrain root CAs to particular URLs/domains was proposed in firefox a while ago[0]. Perhaps an idea whose time has now come? It seems like the principle of least privilege could easily be applied to the CA system rather than trusting all CAs for all domains, as there seem to be obvious/natural constraints in certain cases (like CAs that only operate under a particular country TLD). 0: https://bugzilla.mozilla.org/show_bug.cgi?id=501697 https://bugzilla.mozilla.org/show_bug.cgi?id=501697
tialaramex 7y ago
You should be able to do this for Firefox, in two ways, neither of them very convenient, but if you're excited enough about this to put some work in: 1. The actual browser software has its own rules for what's trusted on top of the root trust store often copy-pasted into other software (e.g. in the Python package Certifi). These rules include name constraints of the sort you're interested in, functionally they're used to constrain roots that might be fine but whose government operators promise they're only for some TLDs under authority of that government, so in a sense for those names the government decides who "really" owns them anyway. Rather than link a horde of HN readers into Mozilla's poor mercurial server I'll point you more indirectly at a summary from their wiki: https://wiki.mozilla.org/CA/Additional_Trust_Changes https://wiki.mozilla.org/CA/Additional_Trust_Changes You can fork Firefox and add your own rules to NSS, or if you're feeling really fancy, your own extension mechanism to add rules at runtime. 2. You can spin up a root, and trust it, and use that to sign a suitable constrained intermediate. Then, destroy the private key for the root and continue using the intermediate. In this scenario Firefox gives total trust to your root, but it can't possibly proxy mybank.com because you destroyed the private keys, it can't do anything further at all. The intermediate, which can still issue, is constrained. Google (I think? Some big tech firm with know-how) has used this trick for products that do loop-back HTTPS. It mints a root cert during instal, issues one certificate and then destroys the private key, then it can trust the root cert but without any danger you later get MITM'd by the root, because that root's private key no longer exists anywhere.
darkhorn 7y ago
> CAA creates a DNS mechanism that enables domain name owners to whitelist CAs that are allowed to issue certificates for their hostnames. https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-cabrowser-forum https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-c...
- tialaramex 7y ago
  CAA isn't relevant here. CAA is a mechanism for trustworthy CAs to agree not to issue certificates to people who don't want them. So if you set CAA to insist you only want Comodo certificates in darkhorn.example, Let's Encrypt will refuse to issue certificates for names under darkhorn.example But no matter how you set CAA for darkhorn.example, my private CA can issue certificates for it no problem. Let's Encrypt aren't _prevented_ from issuing, they are _declining_ to issue by policy, and that policy is part of why the world trusts them. But the world doesn't trust my private CA, so I don't have to follow that policy.

vbezhenar 7y ago

Just issue self-signed certificate for *.mycompany.com, mycompany.org and then put it into trust store, without CA flag set.

schoen 7y ago

No, although the root itself could be scoped that way with an X.509 name constraint. But if you add the root then I believe there's no browser policy to otherwise limit the names for which it can be trusted.

acdha 7y ago
On a tangent, do you know off-hand what browser support for name constraints is like? The last time I looked was a few years ago and at the time it wasn't well supported but if that's improved it'd be a good step for intermediate certs.
- jitbug 7y ago
  It must have been many many years ago, more than 10 at least. Any way to avoid or bypass name or path constraints would be considered a huge and monumental vulnerability today.
  - acdha 7y ago
    > It must have been many many years ago, more than 10 at least. You would be unduly optimistic — for example, Apple did not support them at least as recently as 2015 (see e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=407093#c2 https://bugs.chromium.org/p/chromium/issues/detail?id=407093...) and 10 years ago OpenSSL hadn't even shipped support upstream, plus however long it took your distribution to ship a major version upgrade to 1.0. I was hoping someone might have a pointer to current information on that topic since I believe Apple did finally fix Secure Transport but not when.
    - gnyman 7y ago
      I am afraid I don't have better information on when but some anecdotal information about the state of it. I have done some limited testing and research for our own internal Root CA I got the impression it works nowadays. I have not gotten as far as testing it in production but based on testing Safari and Chrome in https://nameconstraints.bettertls.com/ https://nameconstraints.bettertls.com/ and creating our own name constrained cert and testing it with both OS X Curl and Linux Curl (OpenSSL) I am still of the impression it works. Most other people seem to be sure that it does not though (for example in this discussion and here https://security.stackexchange.com/questions/95600/are-x-509-nameconstraints-on-certificates-supported-on-os-x https://security.stackexchange.com/questions/95600/are-x-509...) so I am not sure if I missed something or if people are just not up to date.
- wiml 7y ago
  The last time I looked into it, a few years ago, everyone except Apple had some basic amount of support. (That is, openssl, firefox, windows, and android — that's all I looked into.) I set up my private CA with name constraints, but I had to mark them noncritical if I wanted iDevices to be able to use the CA at all. But the other systems did at least appear to honor the constraints. I've asked Apple security folks about this a few times, but they just look uncomfortable and change the topic.
mdhardeman 7y ago
Actually true root certs when evaluated by the browsers will have their name constrains within the root certificate themselves ignored. Modern browsers do respect name constraints of intermediate issuing certificates.
- schoen 7y ago
  Thanks for the correction!

burtonator 7y ago

For root certain? But you can add your own self signed certs for domains an they can be wildcards. You only need a root if you're issuing other keys.

deleted 7y ago
[deleted]

y0ghur7_xxx 7y ago

There is a Name Constraints extension in X.509[1] that does exactly that, but to my knowledge no browser implements it. [1] https://tools.ietf.org/html/rfc5280#section-4.2.1.10 https://tools.ietf.org/html/rfc5280#section-4.2.1.10

markovbot 7y ago
and that would have to be baked into the CA certificate, not specified when the CA is trusted. I dont want my browser to ask the CA what it's allowed to do, i want to tell it what it's allowed to do
- y0ghur7_xxx 7y ago
  It has to be baked into the CA, so that a browser vendor can check it before inclusion. If the CA specifies domains it is not allowed to sign certificates for, it will not be included.
jack12 7y ago
> but to my knowledge no browser implements it Firefox does, though I don't know how much they check beyond just the dNSName constraints. Here's the unit test making sure it stays working: https://github.com/mozilla/gecko-dev/blob/b8157dfaafc42deb3b9824ab6aab1c3e11636d76/security/manager/ssl/tests/unit/test_name_constraints.js https://github.com/mozilla/gecko-dev/blob/b8157dfaafc42deb3b...

JoshTriplett 7y ago

I'd like that as well, for exactly the same purpose. To the best of my knowledge, no browser can do this today, and I don't know of any other software that can do that either. (I'd want to have it in the system certificate store with the same constraint, as well.) Name Constraints, as mentioned elsewhere in this thread, wouldn't solve the problem, for two reasons: most software doesn't support them (and silently ignores them rather than correctly failing closed), and they require the CA certificate to contain the constraints rather than system configuration adding the constraints. We need a mechanism to place certificates in a certificate store (browser or system) with specific domain constraints configured by the administrator. To avoid the failure mode of Name Constraints, those certificates shouldn't be accessible to software that doesn't know to enforce domain constraints. That would also require updates to various SSL libraries (and to browsers) to handle this new certificate store and enforce the constraints.

wiml 7y ago
> most software doesn't support [name constraints] (and silently ignores them rather than correctly failing closed) Could you elaborate on this? Specific examples? CVEs? My experience has been that most software will either honor them, or honor the "critical" flag, which is correct (if disappointing) behavior. If you want it to fail closed, use the critical flag. If you want it to fail open, clear the critical flag.
- JoshTriplett 7y ago
  The last time I investigated this this, several years ago, I found that several SSL libraries simply ignored the extension entirely, whether it had "critical" or not. Older OpenSSL did so, for instance. Doing some additional research, it looks like the situation has improved significantly now, and name constraints might actually work as designed if you don't care about older systems. That still doesn't address the ability for a browser/administrator to apply such name constraints to a CA that didn't ship as part of its certificate, though.
jasonh3 7y ago
A mechanism to constrain root CAs to particular URLs/domains was proposed in firefox a while ago[0]. Perhaps an idea whose time has now come? It seems like the principle of least privilege could easily be applied to the CA system rather than trusting all CAs for all domains, as there seem to be obvious/natural constraints in certain cases (like CAs that only operate under a particular country TLD). 0: https://bugzilla.mozilla.org/show_bug.cgi?id=501697 https://bugzilla.mozilla.org/show_bug.cgi?id=501697

tialaramex 7y ago

You should be able to do this for Firefox, in two ways, neither of them very convenient, but if you're excited enough about this to put some work in: 1. The actual browser software has its own rules for what's trusted on top of the root trust store often copy-pasted into other software (e.g. in the Python package Certifi). These rules include name constraints of the sort you're interested in, functionally they're used to constrain roots that might be fine but whose government operators promise they're only for some TLDs under authority of that government, so in a sense for those names the government decides who "really" owns them anyway. Rather than link a horde of HN readers into Mozilla's poor mercurial server I'll point you more indirectly at a summary from their wiki: https://wiki.mozilla.org/CA/Additional_Trust_Changes https://wiki.mozilla.org/CA/Additional_Trust_Changes You can fork Firefox and add your own rules to NSS, or if you're feeling really fancy, your own extension mechanism to add rules at runtime. 2. You can spin up a root, and trust it, and use that to sign a suitable constrained intermediate. Then, destroy the private key for the root and continue using the intermediate. In this scenario Firefox gives total trust to your root, but it can't possibly proxy mybank.com because you destroyed the private keys, it can't do anything further at all. The intermediate, which can still issue, is constrained. Google (I think? Some big tech firm with know-how) has used this trick for products that do loop-back HTTPS. It mints a root cert during instal, issues one certificate and then destroys the private key, then it can trust the root cert but without any danger you later get MITM'd by the root, because that root's private key no longer exists anywhere.

darkhorn 7y ago

> CAA creates a DNS mechanism that enables domain name owners to whitelist CAs that are allowed to issue certificates for their hostnames. https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-cabrowser-forum https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-c...

tialaramex 7y ago
CAA isn't relevant here. CAA is a mechanism for trustworthy CAs to agree not to issue certificates to people who don't want them. So if you set CAA to insist you only want Comodo certificates in darkhorn.example, Let's Encrypt will refuse to issue certificates for names under darkhorn.example But no matter how you set CAA for darkhorn.example, my private CA can issue certificates for it no problem. Let's Encrypt aren't _prevented_ from issuing, they are _declining_ to issue by policy, and that policy is part of why the world trusts them. But the world doesn't trust my private CA, so I don't have to follow that policy.