Puppet reporting fails with handshake_failure #535
Comments
|
I'm getting the same error in Any idea how to fix that? |
|
Ditto. Same problem, OS, etc. |
|
I haven't been able to reproduce it on a fresh CentOS 7 VM with latest puppet. Let's first verify your machine can reach the endpoint and that the cert is trusted (it should be): Can you run Also can you please paste the output of |
|
Hello -
It looks to be an IPv6 DNS issue of some sort. Attempting the curl from my
puppetserver (a machine on AWS) it returns:
[root@puppetmaster-backup mrmike]# curl -v https://api.datadoghq.com
* About to connect() to api.datadoghq.com port 443 (#0)
* Trying 2600:1f18:63f7:b902:7772:c53e:8ccf:7405...
And it gets no further.
Attempting the curl outside of the AWS datacenter I get a valid return
from 34.199.231.39.
If I set /etc/hosts to force the issue on my puppetmaster, I get a return,
showing that there's no firewall or ACL issue on my end.
[root@puppetmaster-backup mrmike]# curl -v https://api.datadoghq.com
* About to connect() to api.datadoghq.com port 443 (#0)
* Trying 34.199.231.39...
* Connected to api.datadoghq.com (34.199.231.39) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=*.datadoghq.com,OU=PositiveSSL Wildcard,OU=Domain
Control Validated
* start date: Jul 13 00:00:00 2016 GMT
* expire date: Oct 12 23:59:59 2019 GMT
* common name: *.datadoghq.com
* issuer: CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO
CA Limited,L=Salford,ST=Greater Manchester,C=GB
GET / HTTP/1.1
User-Agent: curl/7.29.0
Host: api.datadoghq.com
Accept: */*
< HTTP/1.1 307 Temporary Redirect
< Date: Wed, 18 Sep 2019 13:49:31 GMT
< Content-Type: text/html; charset=UTF-8
< Content-Length: 302
< Connection: keep-alive
< Pragma: no-cache
< Cache-Control: no-cache
< Set-Cookie: DD-PSHARD=; Max-Age=0; Path=/; expires=Wed, 31-Dec-97
23:59:59 GMT
< X-DD-VERSION: 35.1707746
< Location: https://api.datadoghq.com/account/login?next=%2F
< X-DD-Debug:
nL/U8Nu7782wU68M7elx8MY/T+2opB0U5/flvjGsH/qXfYEORYWxwdDpQFq78Mxt
< DD-POOL: dogweb_sameorig
< X-Frame-Options: SAMEORIGIN
< X-Content-Type-Options: nosniff
< Strict-Transport-Security: max-age=15724800;
<
<html>
<head>
<title>307 Temporary Redirect</title>
</head>
<body>
<h1>307 Temporary Redirect</h1>
No authenticated user. <a href="
https://api.datadoghq.com/account/login?next=%2F">
https://api.datadoghq.com/account/login?next=%2F</a>;
you should be redirected automatically.
</body>
* Connection #0 to host api.datadoghq.com left intact
</html>
Hopefully we can come up with a better solution than setting my /etc/hosts
file!
Thanks for your attention,
Mike.
…On Wed, Sep 18, 2019 at 6:46 AM Albert Vaca ***@***.***> wrote:
I haven't been able to reproduce it on a fresh CentOS 7 VM.
Let's first verify your machine can reach the endpoint and that the cert
is trusted (it should be): Can you run curl -v https://api.datadoghq.com
and paste the output here?
Also can you please paste the output of puppetserver --version?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#535?email_source=notifications&email_token=AHI7RXTTACC23NQLY4QTEZDQKIIIBA5CNFSM4HYHBX4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD67ZAHI#issuecomment-532647965>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHI7RXRQAETN42TTRKS2ES3QKIIIBANCNFSM4HYHBX4A>
.
--
Sincerely,
Mike McShaffry
|
|
You can make |
|
Curl -6 times out - looks like IPv6 is the culprit. I'll check my ACLs, firewall, etc. Curl -4 works fine, and returns:
< HTTP/1.1 307 Temporary Redirect 307 Temporary RedirectNo authenticated user. https://api.datadoghq.com/account/login?next=%2F; you should be redirected automatically. * Connection #0 to host api.datadoghq.com left intact |
|
Regarding the above - my problem in the AWS datacenter was my SecurityGroup - it was not allowing IPv6 traffic in or out. |
|
This is not my problem: Maybe the issue is triggered because we use a proxy? |
|
In case puppet is using the proxy, then you might want to use the |
|
We are setting http_proxy and https_proxy, and curl uses that already |
|
Your [1] https://github.com/DataDog/dogapi-rb/blob/1.36/lib/dogapi/common.rb#L84 |
|
Note that Datadog's endpoint requires TLS 1.2 or better, and the puppet version you are using is quite old so it might not support that. |
The puppet reporting fails on puppetserver 2.8.1. We are using datadog-datadog_agent (v2.6.0). I manually updated the dogapi gem from 1.22 to 1.36.0 to test if that is an issue, but the behaviour didn't change.
Relevant configuration:
Stacktrace from puppetserver.log:
The text was updated successfully, but these errors were encountered: