Align X509 PARTIAL_CHAIN behavior with 1.1.1 (#1917) #1921
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some consumers noticed that a behavior difference between AWS-LC and OpenSSL when the trust store contains certificates that are issued by other certificates that are also in the trust store. A common example of this would be the trust store containing both the intermediate and the root for the cert chain (`leaf -> intermediate -> root`). The default settings of AWS-LC and OpenSSL require `root` to be self signed for the chain to be verified. Many TLS implementations set the `X509_V_FLAG_PARTIAL_CHAIN` flag however, which allows non self signed certificates to be trusted in the trust store. When `X509_V_FLAG_PARTIAL_CHAIN` is set, OpenSSL 1.1.1 will only verify leaf and intermediate, since intermediate is a trusted certificate. However, AWS-LC will continue building a certificate chain and include root within the chain of trust. This causes a behavioral difference with `X509_STORE_CTX_get0_chain`, where AWS-LC will return all 3 certificates (`leaf -> intermediate -> root`) and OpenSSL 1.1.1 will only return the first two (`leaf -> intermediate `). Our upstream forked a bit before OpenSSL 1.0.2, so we don't have the new behavior. This described behavioral difference was introduced in openssl/openssl@d9b8b89 (along with many others), but the commit introduces too many backwards incompatible changes for us to take as a whole. This subtle difference was due to [OpenSSL 1.1.1 continuously checking for trust while the chain's being established. The search for the next valid cert breaks early as soon as a valid chain has been built. Our current behavior builds the chain with all possible certs first and only breaks the loop if the final cert in the chain is self-signed. We can inherit this part of 1.1.1's new behavior to fix this issue. ### Call-outs: I don't believe this really changes our X509 chain building or verification by much. We're only adding an additional check for trust while the chain is being established and the final chain still needs to go through the same building/verification process that exists in AWS-LC today. ### Testing: Specific test for new behavior in `X509_V_FLAG_PARTIAL_CHAIN` By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license. (cherry picked from commit 9fbfa70)
skmcgrail
approved these changes
Oct 16, 2024
torben-hansen
approved these changes
Oct 16, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some consumers noticed that a behavior difference between AWS-LC and OpenSSL when the trust store contains certificates that are issued by other certificates that are also in the trust store. A common example of this would be the trust store containing both the intermediate and the root for the cert chain (
leaf -> intermediate -> root). The default settings of AWS-LC and OpenSSL requirerootto be self signed for the chain to be verified.Many TLS implementations set the
X509_V_FLAG_PARTIAL_CHAINflag however, which allows non self signed certificates to be trusted in the trust store. WhenX509_V_FLAG_PARTIAL_CHAINis set, OpenSSL 1.1.1 will only verify leaf and intermediate, since intermediate is a trusted certificate. However, AWS-LC will continue building a certificate chain and include root within the chain of trust. This causes a behavioral difference withX509_STORE_CTX_get0_chain, where AWS-LC will return all 3 certificates (leaf -> intermediate -> root) and OpenSSL 1.1.1 will only return the first two (leaf -> intermediate).Our upstream forked a bit before OpenSSL 1.0.2, so we don't have the new behavior. This described behavioral difference was introduced in openssl/openssl@d9b8b89 (along with many others), but the commit introduces too many backwards incompatible changes for us to take as a whole.
This subtle difference was due to OpenSSL 1.1.1 continuously checking for trust while the chain's being established. The search for the next valid cert breaks early as soon as a valid chain has been built. Our current behavior builds the chain with all possible certs first and only breaks the loop if the final cert in the chain is self-signed. We can inherit this part of 1.1.1's new behavior to fix this issue.
Call-outs:
I don't believe this really changes our X509 chain building or verification by much. We're only adding an additional check for trust while the chain is being established and the final chain still needs to go through the same building/verification process that exists in AWS-LC today.
Testing:
Specific test for new behavior in
X509_V_FLAG_PARTIAL_CHAINBy submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.
(cherry picked from commit 9fbfa70)
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.