Welcome to the staging ground for new communities! Each proposal has a description in the "Descriptions" category and a body of questions and answers in "Incubator Q&A". You can ask questions (and get answers, we hope!) right away, and start new proposals.
What happens to TLS name constraints when the client does not support them? Question
I only have a working knowledge of TLS.
TLS today supports name constraints, to restrict which domains a CA can issue certs for: https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10
I've seen people claim that certain software doesn't support this feature: https://serverfault.com/questions/670725/is-it-possible-to-restrict-the-use-of-a-root-certificate-to-a-domain/764699#comment1029498_764699 I think that NCs were not always part of the standard, or at least not always commonly used in the past, so it would not surprise me if there's legacy software out there that pretends they don't exist.
Suppose that:
- User navigates to
https://example.com - Host presents TLS cert signed by Acme Root CA
- User has Acme Root CA installed
- However, the installed cert has a name constraint that does not allow it to sign
example.com - The user's program does not have proper support for name constraints
What will happen? Will the cert be refused or accepted?
I understand it's not possible for answers to have comprehensive knowledge of every TLS misimplementation out there. I am asking:
- What is the logical way to future proof TLS code against future features like NCs?
- What is common practice for TLS devs dealing with possible future features?
- Does TLS itself have any built-in mechanism for handling new features that did not exist when a given client was developed?
Basically, what I'm trying to understand is: When I use NCs, is legacy or poorly developed software very vulnerable because they did not explicitly handle NCs, or will it probably fail gracefully?
1 answer
The following users marked this post as Works for me:
| User | Comment | Date |
|---|---|---|
| matthewsnyder | (no comment) | Mar 5, 2024 at 21:17 |
If both the CA and the client software follow the RFC, the client software will refuse the cert.
Section 4.2 (Certificate Extensions) of the RFC you link states
... Each extension in a certificate is designated as either critical or non-critical. A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized. ...
And section 4.2.1.10 (Name Constraints) states
... Conforming CAs MUST mark this extension as critical ...
0 comment threads
0 comment threads