-
Feature Request
-
Resolution: Done
-
Normal
-
None
-
None
-
None
-
False
-
None
-
False
-
100% To Do, 0% In Progress, 0% Done
- Proposed title of this feature request
2. What is the nature and description of the request?
3. Why does the customer need this? (List the business requirements here)
4. List any affected packages or components.
Customers often lack expertise in dealing with TLS certificates and encounter a number of problems with certificates. ACS should make it easier to understand the root problem and suggest resolution.
When adding custom certificates signed by a local CA to Central for the purpose of resolving the "Insecure" warning in the browser:
- customers fail to add the CA cert for trust
- customers add only the root and miss the intermediate certs
- validation code in ACS is sensitive to the order of intermediate certs in a chain
Often this issue only surfaces during specific scenarios, like when Collector is retrieving a kernel module that it wasn't built with. For this retrieval, collector uses a different TLS codepath and can encounter an x509 validation error even when GRPCS connection to Sensor is working.
(I'm told that because internal ACS TLS uses only the self-signed certificates from Central, ACS TLS communication can work fine, while certs are broken)
Certificate problems also arise when contacting external endpoints like integrations. The UI pops up only a "x.509 certificate validation error"
Some ideas that would make this situation easier for customers to self-resolve:
- UI indication in System Health about a certificate trust problem
- More helpful UI information about certificate trust, links to documents
- documentation on common problems and how to solve them, document an "ideal" situation for custom CA certs