c622e8e4d3
## Review A dedicated reviewer checked the rule description successfully for: - [x] logical errors and incorrect information - [x] information gaps and missing content - [x] text style and tone - [x] PR summary and labels follow [the guidelines](https://github.com/SonarSource/rspec/#to-modify-an-existing-rule) --------- Co-authored-by: hendrik-buchwald-sonarsource <64110887+hendrik-buchwald-sonarsource@users.noreply.github.com>
21 lines
1014 B
Plaintext
21 lines
1014 B
Plaintext
To fix the vulnerability of disabled hostname validation, it is strongly
|
|
recommended to first re-enable the default validation and fix the root cause: the validity of the certificate.
|
|
|
|
==== Use valid certificates
|
|
|
|
If a hostname validation failure prevents connecting to the target server, keep
|
|
in mind that **one system's code should not work around another system's problems**,
|
|
as this creates unnecessary dependencies and can lead to reliability issues.
|
|
|
|
Therefore, the first solution is to change the remote host's certificate to
|
|
match its identity. If the remote host is not under your control, consider replicating its
|
|
service to a server whose certificate you can change yourself.
|
|
|
|
In case the contacted host is located on a development machine, and if there
|
|
is no other choice, try following this solution:
|
|
|
|
* Create a self-signed certificate for that machine.
|
|
* Add this self-signed certificate to the system's trust store.
|
|
* If the hostname is not `localhost`, add the hostname in the `/etc/hosts` file.
|
|
|