You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Anywhere SSl/TLS is configured in RabbitMQ, if the user does not configure cacertfile or cacerts, RabbitMQ should automatically use public_key:cacerts_get/0 to load the system certificates.
If, after doing all of that, RabbitMQ could set verify to verify_none. Otherwise, the ssl functions will fail as reported in erlang/otp#8066
Note that I've never seen cacerts used in practice.
The text was updated successfully, but these errors were encountered:
I don't think that we should widely fall back to verify_none. Certainly not for client connections. using public_key:cacerts_get/0 as a fallback is a good idea.
References:
ssl
client / server options could be more user friendly erlang/otp#8066API: https://www.erlang.org/doc/man/public_key#cacerts_get-0
Anywhere SSl/TLS is configured in RabbitMQ, if the user does not configure
cacertfile
orcacerts
, RabbitMQ should automatically usepublic_key:cacerts_get/0
to load the system certificates.If, after doing all of that, RabbitMQ could set
verify
toverify_none
. Otherwise, thessl
functions will fail as reported in erlang/otp#8066Note that I've never seen
cacerts
used in practice.The text was updated successfully, but these errors were encountered: