5 ms·

I wish there was a way to just get a wildcard and use it to issue "sub certificates" of some sort. ie: *.internal.mycompany.com could be used to issue valid cer

I wish there was a way to just get a wildcard and use it to issue "sub certificates" of some sort. ie: *.internal.mycompany.com could be used to issue valid certs for git.internal.mycompany.com...

mholt 8y ago
As opposed to just using the wildcard itself?
- ozim 8y ago
  You know wildcard is not working two levels down, you are getting .yourdomain.com but not .*.yourdomain.com. But yea maybe parent poster could consider scheme: git-internal.yourdomain.com.
- michaelt 8y ago
  If one of Google's servers gets hacked, I'd rather the hacker get the mail-sor-f41.google.com certificate than the *.google.com certificate :)
  - mholt 8y ago
    But certificates are PUBLIC keys...
    - majewsky 8y ago
      It's evident that GP is referring to the private keys.
      - mholt 8y ago
        No, it's not.
    - 420codebro 8y ago
      Let's say a single VM or docker container has a break-out exploit. They get the private key for (whatever).domain.tld. It would be nice to be able to issue whatever yourself, rather than having to A) do wildcards or B) expose every single record to CT. But I personally don't tie privacy to DNS. Best systems I've seen which handle sensitive stuff have very ambiguous DNS names which you would never guess what they really are.
    - tracker1 8y ago
      And how would one use the cert on a server for a secure connection without the corresponding PRIVATE key exactly?
deathanatos 8y ago
That would be a CA certificate w/ a nameConstraints extension; from RFC 5280, §4.2.1.10[1]: > The name constraints extension, which MUST be used only in a CA certificate, indicates a name space within which all subject names in subsequent certificates in a certification path MUST be located. That is, you get a CA certificate signed by some trusted CA; that essentially makes you a CA; the nameConstraints section restricts it to a certain set of names, so the rest of us are okay w/ you being a CA as we know you can't issue for google.com. E.g., a nameConstraint of ".mycompany.com" allows you to issue under mycompany.com. Sadly, and this is the key bit, AFAIK, this is completely unsupported by browsers¹ and CAs. So, it's not possible to get one, and AFAIK, even if you did, it wouldn't work. I really wish this was different, since it would make the whole certificate thing considerably easier for a lot of usecases, IMO, and is a more sensible way of doing things. [1]: https://tools.ietf.org/html/rfc5280#section-4.2.1.10 https://tools.ietf.org/html/rfc5280#section-4.2.1.10 ¹I think Firefox might support them, but I think that might be it.
- tialaramex 8y ago
  It's mostly policy not technology that forbids this If you control a name constrained subCA for example.com, then new leaf certificates can appear under there at your whim, but there are a bunch of rules that need to be followed for leaf certificates, so how do those get enforced? The root CA is responsible for ensuring they are. One option is you could say OK, they just don't. So then certificates under these constrained subCAs are _worse_ than the rest of the Web PKI, why should we trust these subCAs? Clearly browsers should forcibly distrust them in that case. Another option is, the root CA has physical control and all issuance goes through them anyway. But if you do this (and a few outfits have done it) then there's no practical benefit to the constrained subCA existing at all. It's just extra baggage.
  - deathanatos 8y ago
    While I admit I don't know all the rules that govern CAs, can you name one that would be at issue here? I would presume that, at the time you're issuing the name-constrained CA certificate, you would issue a challenge to prove ownership of the domain, much as you would for a non-CA cert. Why would that not suffice?

I wish there was a way to just get a wildcard and use it to issue "sub certificates" of some sort. ie: *.internal.mycompany.com could be used to issue valid certs for git.internal.mycompany.com...

mholt 8y ago

As opposed to just using the wildcard itself?

ozim 8y ago
You know wildcard is not working two levels down, you are getting .yourdomain.com but not .*.yourdomain.com. But yea maybe parent poster could consider scheme: git-internal.yourdomain.com.
michaelt 8y ago
If one of Google's servers gets hacked, I'd rather the hacker get the mail-sor-f41.google.com certificate than the *.google.com certificate :)
- mholt 8y ago
  But certificates are PUBLIC keys...
  - majewsky 8y ago
    It's evident that GP is referring to the private keys.
    - mholt 8y ago
      No, it's not.
  - 420codebro 8y ago
    Let's say a single VM or docker container has a break-out exploit. They get the private key for (whatever).domain.tld. It would be nice to be able to issue whatever yourself, rather than having to A) do wildcards or B) expose every single record to CT. But I personally don't tie privacy to DNS. Best systems I've seen which handle sensitive stuff have very ambiguous DNS names which you would never guess what they really are.
  - tracker1 8y ago
    And how would one use the cert on a server for a secure connection without the corresponding PRIVATE key exactly?

deathanatos 8y ago

That would be a CA certificate w/ a nameConstraints extension; from RFC 5280, §4.2.1.10[1]: > The name constraints extension, which MUST be used only in a CA certificate, indicates a name space within which all subject names in subsequent certificates in a certification path MUST be located. That is, you get a CA certificate signed by some trusted CA; that essentially makes you a CA; the nameConstraints section restricts it to a certain set of names, so the rest of us are okay w/ you being a CA as we know you can't issue for google.com. E.g., a nameConstraint of ".mycompany.com" allows you to issue under mycompany.com. Sadly, and this is the key bit, AFAIK, this is completely unsupported by browsers¹ and CAs. So, it's not possible to get one, and AFAIK, even if you did, it wouldn't work. I really wish this was different, since it would make the whole certificate thing considerably easier for a lot of usecases, IMO, and is a more sensible way of doing things. [1]: https://tools.ietf.org/html/rfc5280#section-4.2.1.10 https://tools.ietf.org/html/rfc5280#section-4.2.1.10 ¹I think Firefox might support them, but I think that might be it.

tialaramex 8y ago
It's mostly policy not technology that forbids this If you control a name constrained subCA for example.com, then new leaf certificates can appear under there at your whim, but there are a bunch of rules that need to be followed for leaf certificates, so how do those get enforced? The root CA is responsible for ensuring they are. One option is you could say OK, they just don't. So then certificates under these constrained subCAs are _worse_ than the rest of the Web PKI, why should we trust these subCAs? Clearly browsers should forcibly distrust them in that case. Another option is, the root CA has physical control and all issuance goes through them anyway. But if you do this (and a few outfits have done it) then there's no practical benefit to the constrained subCA existing at all. It's just extra baggage.
- deathanatos 8y ago
  While I admit I don't know all the rules that govern CAs, can you name one that would be at issue here? I would presume that, at the time you're issuing the name-constrained CA certificate, you would issue a challenge to prove ownership of the domain, much as you would for a non-CA cert. Why would that not suffice?