3 ms·

I'm taking this opportunity to once again ask for the widespread adoption of the Name Constraints extension in x509, and subsequent roll-out of constrained inte

I'm taking this opportunity to once again ask for the widespread adoption of the Name Constraints extension in x509, and subsequent roll-out of constrained intermediate CA certs signed by a publicly trusted root. Would be so convenient to have an intermediate CA cert constrained to *.my-name.com to avoid situations like this. Being forced to either use a private PKI infrastructure or using wildcards to not leak host names is so annoying.

supriyo-biswas 2y ago
Let’s encrypt and similar ACME compliant services allow you to get wildcard certs through their DNS-01 challenge.
- lxgr 2y ago
  A wildcard cert is an unnecessary risk, though. Just because I trust a server to hold the cert for preview.example.com doesn’t mean I’d want it to be able to pose as prod.example.com, for example.
  - nlitened 2y ago
    Why? As I understand it, the domain owner can assign the name you “trust” to any server already. Might as well trust all names by that domain owner.
    - freedomben 2y ago
      Because if your one wildcard cert gets compromised somehow, the attacker can now impersonate every subdomain of yours. Consider what happens if there's an old test box called daves-test-box.example.com that has a copy of the wildcard cert valid for *.example.com. Dave quits and never updates his box. Eventually an unpatched CVE gets used to steal the cert. Now the attacker can phish or MitM your users of www.example.com using the stolen cert and browsers will trust it. If you'd instead of wilcard certs used specific ones, then the only thing the attacker can do with it is MitM or phish the users of Dave's test box, which is approximately zero. There are certainly other strategies and best practices that can mitigate the risk in this scenario, but not using wildcards is a good one to include.
      - White_Wolf 2y ago
        I don't think you realize the ammount or scrutiny and approvals required to allow an exployee to use a sub on the main domain in corp.. A very very.. very limited ammount or people can do DNS changes for the main domain with a crap ton of signatures and eyes monitoring the whole thing. Dave can test his stuff on a newly bought domain for testing or the internal domains.
      - blagie 2y ago
        It depends on the system design. If I have an organization like Google, with many employees, *.google.com would be a horrible cert. That's not every organization. I maintain many groups of /related/ servers (including dynamic ones which appear and disappear at whim). There, a wildcard makes a lot of sense. If I have https://[username].[domain]/ https://[username].[domain]/, https://[git https://[git project].[domain]/, https://[client].[domain]/ https://[client].[domain]/ or similar, that integrates nicely with a lot of security infrastructure in ways which http://[domain]/client/ http://[domain]/client/ don't. E.g. A network can filter https based on domains, but can't look inside the envelope. A browser will highlight domains to users who want to know where they are. Etc. There are also many good reasons why managing one credential per server (which can map to many domains) is better practice than managing a dizzying array of credentials. So I agree about the general best practice, but there are exceptions. Mandating (as opposed to recommending / encouraging) non-universal best practices is usually bad practice.
        freedomben 2y ago
        Yes, I could not agree more. I've been in both the dynamic servers and the dizzying array situations and those are absolutely good reasons to use a wildcard. I worked for a company that white-labelled services so every customer had a vanity subdomain, and managing certs because an utter nightmare until we finally just bought a wildcard. Recommending encouraging non-wildcard certs is the optimal strategy. Only thing I would add, is recommending default to non-wildcard and evaluate deviations case by case.
      - tasuki 2y ago
        No one is saying wildcard certificates should be mandatory. An old test box shouldn't have a wildcard certificate for sure. Yours is not an argument against wildcard certificates! Yes, like, everything else ever, wildcard certificates can be misused.
  - Sayrus 2y ago
    A server allowed to hold preview.example.com (and its associated DNS records) cannot pass dns-01 for *.example.com. Unless you have no authz on your DNS configuration, in which case this server is allowed to hold prod.example.com since it can edit that record.
    - freedomben 2y ago
      The main point of DNS-01 is that it doesn't have to be the same machine requesting the cert and using it. You can easily use DNS-01 from your laptop to get a cert for prod boxes. I have a script that runs as a k8s cron job that uses DNS-01 to renew all the certs and stick them in k8s secrets automatically.
    - lxgr 2y ago
      I know, but what I mean is that just getting a wildcard cert and handing it to all servers that need it comes with some tradeoffs, as does requesting a single-host cert publicly for each host (mainly that I need to talk to a CA, which needs to be available, and it'll publicly log a possibly internal-only, preview etc. hostname). Having domain-constrained sub-CA certificates granted by the exact same mechanism we use for wildcard certs today would combine the advantages of both.
  - freedomben 2y ago
    As with most things, it's a tradeoff of security vs convenience/usability. The CIA Triad comes to mind. I advocate for using separate domains for dev, staging, and prod (at least prod vs. non-prod) and for a wildcard cert for a non-prod domain, the convenience far outweighs the security risk IMHO. But yeah generally speaking, it's best to avoid wildcards unless there's an actual benefit to using them, even when it's not a prod domain.
    - couchand 2y ago
      And the beautiful thing about domains is that they're hierarchical, so you can arbitrarily split your trust boundaries.
      - blagie 2y ago
        A cert for .test.domain seems reasonable, for example, especially if the test infrastructure is dynamic, and you e.g. have CI/CD for a Cartesian product of: every branch * several test data sets * several feature flag / configuration sets * ...
lxgr 2y ago
This would be so great. It also just mirrors the DNS trust model nicely, which is what’s used for X.509 trust anyway by most CAs.
lambdaxyzw 2y ago
The point of certificate transparency is to have a public audit log of every certificate issued. Even if you had your own CA, you would be obliged to report every certificate you issue to the CT. This is a feature, not a bug.
- vbezhenar 2y ago
  Certificate Transparency needed to serve website owners and not some greater good. Knowing that someone issued wildcard is enough.
  - jchw 2y ago
    Certificate Transparency really serves the end user. Because the most popular browsers (at least Chrome and Safari) generally require CT logged certificates, if you want to successfully perform a MitM attack against any user, even just some individual user, even controlling a CA, you still can't do so without publishing your fraudulent certificate to a CT log. This is the important function of the CT log. It is an effective balance against compromised CAs and governments that might abuse CAs, because it causes such attacks to become quickly tamper-evident. I don't think it would be possible for a system like this to be effective without publishing the actual certificate to the log.
    - vbezhenar 2y ago
      I don't follow your threat model. Let's say that browser is fine with CT if either leaf or intermediate certificate is logged. If you need to issue fake certificate, you need to either log it, or you need to issue fake intermediate certificate and log it. Either way it's visible to website owner (and other people likely won't care anyway).
      - jchw 2y ago
        It would be completely possible to do it that way, but doing it this way ensures that at no point does certificate issuance become opaque and impossible to scrutinize. We want to ensure that CAs follow certain rules, and CT logs are one way to do this. For example, a CA should not issue a certificate with a forged "not before" time. There are certainly many more cases like this. Public CT logs mean that the property of transparent certificate issuance extends to the entire Internet, which is good. If you want private certs, you can use a private CA and deploy it to the machines in your domain. Totally reasonable alternative in my opinion.
michaelt 2y ago
You can just buy a regular wildcard certificate for *.my-name.com If your organisation is competent enough to handle an intermediate CA certificate safely, you're certainly competent to handle a wildcard cert safely which is a much easier task. Sadly it's unlikely you'll ever see the Name Constraints extension adopted. All it takes is one model of 15 year old smart TV failing to respect it, and the CA/Browser Forum will consider it too dangerous to allow.
- filleokus 2y ago
  While I principally agree, the neat thing with the intermediate CA is that it can be centralised and support ACME, which makes maintaining the certs so much easier. In my current org we have hundreds of TLS termination "configuration points" (cdn's & cloud loadbalancers / networking appliances / k8s ingress controllers / raw VM's). We have standardised on ACME issued certs for almost everything. Using a wildcard certificate would force us back to manual cert updating procedures, or finicky scripts. Undoubtedly causing issues when certs become expired. (Not to mention the trust boundaries. An org can be competent enough to handle an in-house CA securely, and simultaneously have a bunch of quasi-sloppy vendors for stuff like the visitor badge kiosk.) But I sadly agree that it will probably never happen…
tru3_power 2y ago
As a red teamer I agree - I always found this ridiculous

supriyo-biswas 2y ago

Let’s encrypt and similar ACME compliant services allow you to get wildcard certs through their DNS-01 challenge.

lxgr 2y ago
A wildcard cert is an unnecessary risk, though. Just because I trust a server to hold the cert for preview.example.com doesn’t mean I’d want it to be able to pose as prod.example.com, for example.
- nlitened 2y ago
  Why? As I understand it, the domain owner can assign the name you “trust” to any server already. Might as well trust all names by that domain owner.
  - freedomben 2y ago
    Because if your one wildcard cert gets compromised somehow, the attacker can now impersonate every subdomain of yours. Consider what happens if there's an old test box called daves-test-box.example.com that has a copy of the wildcard cert valid for *.example.com. Dave quits and never updates his box. Eventually an unpatched CVE gets used to steal the cert. Now the attacker can phish or MitM your users of www.example.com using the stolen cert and browsers will trust it. If you'd instead of wilcard certs used specific ones, then the only thing the attacker can do with it is MitM or phish the users of Dave's test box, which is approximately zero. There are certainly other strategies and best practices that can mitigate the risk in this scenario, but not using wildcards is a good one to include.
    - White_Wolf 2y ago
      I don't think you realize the ammount or scrutiny and approvals required to allow an exployee to use a sub on the main domain in corp.. A very very.. very limited ammount or people can do DNS changes for the main domain with a crap ton of signatures and eyes monitoring the whole thing. Dave can test his stuff on a newly bought domain for testing or the internal domains.
    - blagie 2y ago
      It depends on the system design. If I have an organization like Google, with many employees, *.google.com would be a horrible cert. That's not every organization. I maintain many groups of /related/ servers (including dynamic ones which appear and disappear at whim). There, a wildcard makes a lot of sense. If I have https://[username].[domain]/ https://[username].[domain]/, https://[git https://[git project].[domain]/, https://[client].[domain]/ https://[client].[domain]/ or similar, that integrates nicely with a lot of security infrastructure in ways which http://[domain]/client/ http://[domain]/client/ don't. E.g. A network can filter https based on domains, but can't look inside the envelope. A browser will highlight domains to users who want to know where they are. Etc. There are also many good reasons why managing one credential per server (which can map to many domains) is better practice than managing a dizzying array of credentials. So I agree about the general best practice, but there are exceptions. Mandating (as opposed to recommending / encouraging) non-universal best practices is usually bad practice.
      - freedomben 2y ago
        Yes, I could not agree more. I've been in both the dynamic servers and the dizzying array situations and those are absolutely good reasons to use a wildcard. I worked for a company that white-labelled services so every customer had a vanity subdomain, and managing certs because an utter nightmare until we finally just bought a wildcard. Recommending encouraging non-wildcard certs is the optimal strategy. Only thing I would add, is recommending default to non-wildcard and evaluate deviations case by case.
    - tasuki 2y ago
      No one is saying wildcard certificates should be mandatory. An old test box shouldn't have a wildcard certificate for sure. Yours is not an argument against wildcard certificates! Yes, like, everything else ever, wildcard certificates can be misused.
- Sayrus 2y ago
  A server allowed to hold preview.example.com (and its associated DNS records) cannot pass dns-01 for *.example.com. Unless you have no authz on your DNS configuration, in which case this server is allowed to hold prod.example.com since it can edit that record.
  - freedomben 2y ago
    The main point of DNS-01 is that it doesn't have to be the same machine requesting the cert and using it. You can easily use DNS-01 from your laptop to get a cert for prod boxes. I have a script that runs as a k8s cron job that uses DNS-01 to renew all the certs and stick them in k8s secrets automatically.
  - lxgr 2y ago
    I know, but what I mean is that just getting a wildcard cert and handing it to all servers that need it comes with some tradeoffs, as does requesting a single-host cert publicly for each host (mainly that I need to talk to a CA, which needs to be available, and it'll publicly log a possibly internal-only, preview etc. hostname). Having domain-constrained sub-CA certificates granted by the exact same mechanism we use for wildcard certs today would combine the advantages of both.
- freedomben 2y ago
  As with most things, it's a tradeoff of security vs convenience/usability. The CIA Triad comes to mind. I advocate for using separate domains for dev, staging, and prod (at least prod vs. non-prod) and for a wildcard cert for a non-prod domain, the convenience far outweighs the security risk IMHO. But yeah generally speaking, it's best to avoid wildcards unless there's an actual benefit to using them, even when it's not a prod domain.
  - couchand 2y ago
    And the beautiful thing about domains is that they're hierarchical, so you can arbitrarily split your trust boundaries.
    - blagie 2y ago
      A cert for .test.domain seems reasonable, for example, especially if the test infrastructure is dynamic, and you e.g. have CI/CD for a Cartesian product of: every branch * several test data sets * several feature flag / configuration sets * ...

lxgr 2y ago

This would be so great. It also just mirrors the DNS trust model nicely, which is what’s used for X.509 trust anyway by most CAs.

lambdaxyzw 2y ago

The point of certificate transparency is to have a public audit log of every certificate issued. Even if you had your own CA, you would be obliged to report every certificate you issue to the CT. This is a feature, not a bug.

vbezhenar 2y ago
Certificate Transparency needed to serve website owners and not some greater good. Knowing that someone issued wildcard is enough.
- jchw 2y ago
  Certificate Transparency really serves the end user. Because the most popular browsers (at least Chrome and Safari) generally require CT logged certificates, if you want to successfully perform a MitM attack against any user, even just some individual user, even controlling a CA, you still can't do so without publishing your fraudulent certificate to a CT log. This is the important function of the CT log. It is an effective balance against compromised CAs and governments that might abuse CAs, because it causes such attacks to become quickly tamper-evident. I don't think it would be possible for a system like this to be effective without publishing the actual certificate to the log.
  - vbezhenar 2y ago
    I don't follow your threat model. Let's say that browser is fine with CT if either leaf or intermediate certificate is logged. If you need to issue fake certificate, you need to either log it, or you need to issue fake intermediate certificate and log it. Either way it's visible to website owner (and other people likely won't care anyway).
    - jchw 2y ago
      It would be completely possible to do it that way, but doing it this way ensures that at no point does certificate issuance become opaque and impossible to scrutinize. We want to ensure that CAs follow certain rules, and CT logs are one way to do this. For example, a CA should not issue a certificate with a forged "not before" time. There are certainly many more cases like this. Public CT logs mean that the property of transparent certificate issuance extends to the entire Internet, which is good. If you want private certs, you can use a private CA and deploy it to the machines in your domain. Totally reasonable alternative in my opinion.

michaelt 2y ago

You can just buy a regular wildcard certificate for *.my-name.com If your organisation is competent enough to handle an intermediate CA certificate safely, you're certainly competent to handle a wildcard cert safely which is a much easier task. Sadly it's unlikely you'll ever see the Name Constraints extension adopted. All it takes is one model of 15 year old smart TV failing to respect it, and the CA/Browser Forum will consider it too dangerous to allow.

filleokus 2y ago
While I principally agree, the neat thing with the intermediate CA is that it can be centralised and support ACME, which makes maintaining the certs so much easier. In my current org we have hundreds of TLS termination "configuration points" (cdn's & cloud loadbalancers / networking appliances / k8s ingress controllers / raw VM's). We have standardised on ACME issued certs for almost everything. Using a wildcard certificate would force us back to manual cert updating procedures, or finicky scripts. Undoubtedly causing issues when certs become expired. (Not to mention the trust boundaries. An org can be competent enough to handle an in-house CA securely, and simultaneously have a bunch of quasi-sloppy vendors for stuff like the visitor badge kiosk.) But I sadly agree that it will probably never happen…

tru3_power 2y ago

As a red teamer I agree - I always found this ridiculous