Skip to content
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

Closed
AndyHunt66 opened this issue Feb 10, 2020 · 1 comment · Fixed by #56090
Assignees
Labels
:Data Management/Watcher Team:Data Management Meta label for data/management team

Comments

@AndyHunt66
Copy link
Contributor

AndyHunt66 commented Feb 10, 2020

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

xpack.notification.email.account:
   smtp1:
       profile: standard
       email_defaults:
           from: Elasticsearch@example.email.com
       smtp:
           ssl.trust: example.email.com
           auth: false
           starttls.enable: true
           host: example.email.com
           port: 25

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:

   "actions": [
      {
        "id": "email_administrator",
        "type": "email",
        "status": "failure",
        "error": {
          "root_cause": [
            {
              "type": "messaging_exception",
              "reason": "failed to send email with subject [lwatch] via account [smtp1]"
            }
          ],
          "type": "messaging_exception",
          "reason": "failed to send email with subject [watch] via account [smtp1]",
          "caused_by": {
            "type": "messaging_exception",
            "reason": "Could not convert socket to TLS",
            "caused_by": {
              "type": "s_s_l_handshake_exception",
              "reason": "PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target",
              "caused_by": {
                "type": "validator_exception",
                "reason": "PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target",
                "caused_by": {
                  "type": "sun_cert_path_builder_exception",
                  "reason": "unable to find valid certification path to requested target"
                }
              }
            }
          }
        }
      }
    ]
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-features (:Core/Features/Watcher)

@tvernum tvernum self-assigned this Feb 11, 2020
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
@rjernst rjernst added the Team:Data Management Meta label for data/management team label May 4, 2020
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
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
:Data Management/Watcher Team:Data Management Meta label for data/management team
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants