/ curl Public
Do not recommend adding --insecure to solve certificate issues #1810
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.
There is a massive amount of scripts, examples and tutorials unconditionally adding the
--insecureoption to the
curlcommand in order to access public servers with perfectly valid certificates.
A possible culprit is the
curlcommand itself. As soon as a certificate error is returned, it suggests simply retrying the same command with
--insecureadded to it. So, people follow the advice, and since it "fixes things", end up using it unconditionally.
This is terrible.
The main causes of certificates that don't validate are:
The following diff displays some hints about what the root cause of a certificate error is likely to be, instead of suggesting