docs: recommend use of appropriately scoped trust roots #4006
+28
−0
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
This change adds an important note to the documentation for `log4j2.trustStoreLocation` and the `TrustStore` plugin, advising users to configure trust stores with trust roots that are appropriate for their communication scope. The recommendation is grounded in public guidance from [NIST SP 800-52 Rev. 2: *Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations*](https://csrc.nist.gov/pubs/sp/800/52/r2/final), which advises minimizing trust anchors to those necessary for the intended connections.
garydgregory
approved these changes
Dec 17, 2025
Member
garydgregory
left a comment
garydgregory
left a comment
There was a problem hiding this comment.
Looks good. The file name "admonition" is weird in this context but that's just me. "guideline" seems better to me but it's not a big deal.
Contributor
Author
|
Thanks! I'll proceed with the rest of my TODO list tomorrow. |
ppkarwasz
added a commit
that referenced
this pull request
Dec 17, 2025
* docs: recommend use of appropriately scoped trust roots This change adds an important note to the documentation for `log4j2.trustStoreLocation` and the `TrustStore` plugin, advising users to configure trust stores with trust roots that are appropriate for their communication scope. The recommendation is grounded in public guidance from [NIST SP 800-52 Rev. 2: *Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations*](https://csrc.nist.gov/pubs/sp/800/52/r2/final), which advises minimizing trust anchors to those necessary for the intended connections. * fix: rename partial
FreeAndNil
approved these changes
Dec 18, 2025
raboof
reviewed
Dec 18, 2025
Comment on lines
+20
to
+23
| Log4j Core typically does not communicate with external organizations; therefore, the default trust store provided by the Java Runtime Environment is often not appropriate. | ||
|
|
||
| When configuring a trust store for Log4j Core, follow established best practices. For example, | ||
| https://csrc.nist.gov/pubs/sp/800/52/r2/final[NIST SP 800-52 Rev. 2] (§4.5.2) recommends using a trust store that contains only the CA certificates required for the intended communication scope, such as a private or enterprise CA. This reduces exposure to unintended or compromised CA certificates included in the default trust store. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
This change adds an important note to the documentation for
log4j2.trustStoreLocationand theTrustStoreplugin, advising users to configure trust stores with trust roots that are appropriate for their communication scope.The recommendation is grounded in public guidance from NIST SP 800-52 Rev. 2: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations, which advises minimizing trust anchors to those necessary for the intended connections.