The feature is called 'RFC 5280 Name Constraints' and nobody will issue you such certificates.
This is because some clients don't support the constraints, so if they give you a CA certificate that can sign any subdomain of evil.com you could use it to sign MITM certificates for good.com and, although you wouldn't fool modern web browsers, you might fool smart fridges and ancient android phones.
You can, however, use it to constrain your in-house corporate CA if you like.
Well our private one does lmao. Not useful in the slightest because of lack of client support.
We had an idea that our dev machines could live under *.dev.example.com and just have sub-ca generating certs for it and so any vulnerability or misgenerated cert would be limited to that environment, but lack of client support means that wouldn't work very well
>You can already do this by effectively getting a pool of wildcard certs.
That is absolutely not "effectively" the same.
If I had a constrained CA cert for my domain, that CA cert would be the high value target which could potentially compromise my entire domain, but I could keep it as secure as I wanted to while issuing certificates for my world-facing machines specific to their own names.
Wildcard certs instead force me to put the high value cert on the world-facing machine. Suddenly every one of my web servers has the ability to impersonate my entire domain, and if compromised the attacker then has the keys to the kingdom.
Wildcard certs are a sorry excuse for a constrained CA cert, and the fact that we're stuck using them is terrible.
The only case where I consider wildcard certs acceptable is on a frontend machine that serves an entire dedicated domain, for example one of my systems has a lot of customername.domain.com and that particular domain is only used for that system, so everything under that domain would be those machines exclusively, making wildcard certs no additional risk.
If your domain use allows a wildcard-equipped web server to impersonate anything unrelated, it's probably a bad idea.
I do not know why this parent got voted down, but I do echo the parent’s sentiment that wildcard on the public-facing TLS/SSL servers still remains a weak point of security (from the server-side security POV).
Purpose of reducing wildcard usage in Subject Name (SAN) to within just the network portion that you control entirely still remains a valid security posture.
There are many types of TLS/SSL servers that can fork off of a public-facing wildcard FQDN; the thing is that ANY other CA (other than ones who signed wildcard CA) can be used to hang off a subdomain portion while its parent domain got differently issued by this wildcard-permitting CA.
The many types of CA end-nodes that can be created (unbeknownst to holder of this wildcard certificate holder) and used as subdomain servers are but not limited to:
1. Non-Leaf Intermediary CA
2. Cross-Certificate CA
3. TLE-Signing CA
4. Email Protection CA
5. Code Signing CA
6. Timestamping Intermediate CA
7. Identity CA
8. TLS Server Certificate
9. TLS Client Certificate
10. OSCP Responder Certificate
11. CRL Certificate
12. Code Signing Certificate
13. Email Protection Certificate
14. Timestamoing Certificate
15. Encryption Certificate
16. OSCP Responder Certificate
This above remains true even if DNSSEC setup is perfectly sound for you still have web (and OS) security to contend with; you also have to contend with correct OpenSSL settings for this wildcard CA sertificate (setting details. in link below).
Details on what OpenSSL settings for above are given in this:
(Note: my website shall be accessible only by non-Chrome web browsers, it is not accessible to Chrome-based clients due to its hardcoded client-side HTTP/2 mandate ignoring and overriding my TLS server’s must have HTTP/1.2-only, ChaCha-only. Chrome is broke, remains my assertion).
> (Note: my website shall be accessible only by non-Chrome web browsers, it is not accessible to Chrome-based clients due to its hardcoded client-side HTTP/2 mandate ignoring and overriding my TLS server’s must have HTTP/1.2-only, ChaCha-only. Chrome is broke, remains my assertion).
I guess everyone needs a hobby lmao. Also what is exactly the problem ? On wireshark I see chrome sending hello with TLS1.2/1.3 and TLS_CHACHA20_POLY1305_SHA256 (0x1303) then getting rejected https://imgur.com/a/HjZormT
Correct. TLSv1.2 is getting obsoleted due to several CVEs, so block that.
I would be talking about my server mandating HTTP/1.3 over Chrome mandating HTTP/2.0 of which Chrome does poorly in concise error messaging. Since my server decides, it fails.
On an unrelated note, stick with TLS v1.3 whenever you can.
I suggest you fix the HTTP TLS-less version of the site, so that chromium browsers may access the plaintext version.
Currently I get a 404 Not Found for the linked HTML file when connecting via plaintext.
TLS only complicated things (: I don't really need to verify the website integrity and privacy when reading an article from a HN commenter I do not know (: Maybe it's only about cosmetics -- a green padlock is more pleasing than a red triangle.
It really is how it should be; get the CA for your domain and manage away, no reliance on 3rd party CA for each issue for certs on your domains.