-
Notifications
You must be signed in to change notification settings - Fork 24.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Regression - ssl.trust no longer working - "unable to find valid certification path to requested target" #52153
Labels
Comments
Pinging @elastic/es-core-features (:Core/Features/Watcher) |
tvernum
added a commit
to tvernum/elasticsearch
that referenced
this issue
May 4, 2020
The ssl.trust setting for Watcher provides a list of hostnames that should be automatically trusted for SSL hostname verification. It was accidentally broken when we added the full ssl.* settings for email notifications (see elastic#45272) This commit corrects this, so the setting is once again respected, as long as none of the other ssl settings are configured for email notifications. Resolves: elastic#52153
tvernum
added a commit
that referenced
this issue
May 28, 2020
The ssl.trust setting for Watcher provides a list of hostnames that should be automatically trusted for SSL hostname verification. It was accidentally broken when we added the full ssl.* settings for email notifications (see #45272) This commit corrects this, so the setting is once again respected, as long as none of the other ssl settings are configured for email notifications. Resolves: #52153
tvernum
added a commit
to tvernum/elasticsearch
that referenced
this issue
May 28, 2020
The ssl.trust setting for Watcher provides a list of hostnames that should be automatically trusted for SSL hostname verification. It was accidentally broken when we added the full ssl.* settings for email notifications (see elastic#45272) This commit corrects this, so the setting is once again respected, as long as none of the other ssl settings are configured for email notifications. Resolves: elastic#52153 Backport of: elastic#56090
tvernum
added a commit
to tvernum/elasticsearch
that referenced
this issue
May 28, 2020
The ssl.trust setting for Watcher provides a list of hostnames that should be automatically trusted for SSL hostname verification. It was accidentally broken when we added the full ssl.* settings for email notifications (see elastic#45272) This commit corrects this, so the setting is once again respected, as long as none of the other ssl settings are configured for email notifications. Resolves: elastic#52153 Backport of: elastic#56090
This was referenced May 28, 2020
tvernum
added a commit
to tvernum/elasticsearch
that referenced
this issue
May 28, 2020
The ssl.trust setting for Watcher provides a list of hostnames that should be automatically trusted for SSL hostname verification. It was accidentally broken when we added the full ssl.* settings for email notifications (see elastic#45272) This commit corrects this, so the setting is once again respected, as long as none of the other ssl settings are configured for email notifications. Resolves: elastic#52153 Backport of: elastic#56090
tvernum
added a commit
to tvernum/elasticsearch
that referenced
this issue
May 28, 2020
The ssl.trust setting for Watcher provides a list of hostnames that should be automatically trusted for SSL hostname verification. It was accidentally broken when we added the full ssl.* settings for email notifications (see elastic#45272) This commit corrects this, so the setting is once again respected, as long as none of the other ssl settings are configured for email notifications. Resolves: elastic#52153 Backport of: elastic#56090
tvernum
added a commit
that referenced
this issue
May 28, 2020
The ssl.trust setting for Watcher provides a list of hostnames that should be automatically trusted for SSL hostname verification. It was accidentally broken when we added the full ssl.* settings for email notifications (see #45272) This commit corrects this, so the setting is once again respected, as long as none of the other ssl settings are configured for email notifications. Resolves: #52153 Backport of: #56090
tvernum
added a commit
that referenced
this issue
May 28, 2020
The ssl.trust setting for Watcher provides a list of hostnames that should be automatically trusted for SSL hostname verification. It was accidentally broken when we added the full ssl.* settings for email notifications (see #45272) This commit corrects this, so the setting is once again respected, as long as none of the other ssl settings are configured for email notifications. Resolves: #52153 Backport of: #56090
tvernum
added a commit
that referenced
this issue
May 28, 2020
The ssl.trust setting for Watcher provides a list of hostnames that should be automatically trusted for SSL hostname verification. It was accidentally broken when we added the full ssl.* settings for email notifications (see #45272) This commit corrects this, so the setting is once again respected, as long as none of the other ssl settings are configured for email notifications. Resolves: #52153 Backport of: #56090
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Elasticsearch version (
bin/elasticsearch --version
): 7.5.0(also affects 7.4.0+)
Description of the problem including expected versus actual behavior:
This pr and it's backport have caused
xpack.notification.email.account.<name>.smtp.ssl.trust
to not be recognised any more.The following config works for versions 6.8.4, 7.0.0,7.1.0,7.2.0,7.3.2, but fails for versions 7.4.0+, 7.5.0 with the message:
unable to find valid certification path to requested target
It's unclear if this is the new intended behaviour, or if this is an unwanted side-effect of #45272
Steps to reproduce
1 - setup smtp configuration as above, then create a watcher that fires an email via smtp
Provide logs (if relevant):
Watch result:
The text was updated successfully, but these errors were encountered: