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.
|
||
|
|
|