I have an rest api that was working well few days ago. However , it stopped working. When I checked the access_token , it is not expired. Has anybody encountered such problem?
But the get method gives following error when I checked in rest client app :
Trying 99.86.230.110...
Name '0.0.0.0' family 2 resolved to '0.0.0.0' family 2
Local port: 0
Connected to api-v2.myapi.it.com (99.86.230.110) port 443 (#0)
ALPN, offering http/1.1
Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
successfully set certificate verify locations:
CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
TLSv1.2 (OUT), TLS header, Certificate Status (22):
TLSv1.2 (OUT), TLS handshake, Client hello (1):
TLSv1.2 (IN), TLS header, Unknown (21):
TLSv1.2 (IN), TLS alert, Server hello (2):
error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Closing connection 0
This is a TLS problem and has nothing to do with access tokens. The problem is on the server side, i.e. the server aborts the TLS handshake with a TLS alert "handshake failure". Since this is happening immediately after the client initiated the TLS handshake and before any server certificate is send it might be a misconfigured server which cannot find its certificate. Check with the API provider of why there systems suddenly have problems.
Related
Several days ago tailscale on my rasberry pi 4 stopped working, I thought it is another wifi issue and rebooted it but after looking at logs I realized wifi isnt issue but in tailscale connectivity:
sudo systemctl status tailscaled.service
tailscaled[154215]: control: LoginInteractive -> regen=true
tailscaled[154215]: control: doLogin(regen=true, hasUrl=false)
tailscaled[154215]: Received error: fetch control key: Get "https://controlplane.tailscale.com/key?v=57": context deadline exceeded
tailscaled[154215]: logtail: upload: log upload of 23460 bytes compressed failed: Post "https://log.tailscale.io/c/tailnode.log.tailscale.io/<>": net/http: TLS handshake timeout
tailscaled[154215]: logtail: [v1] backoff: 27325 msec
tailscale debug ts2021
02:19:14.305767 Fetching keys from https://controlplane.tailscale.com/key?v=57 ...
02:19:24.410086 Do: Get "https://controlplane.tailscale.com/key?v=57": net/http: TLS handshake timeout
Get "https://controlplane.tailscale.com/key?v=57": net/http: TLS handshake timeout
but curl can GET page without any issue
curl -v https://controlplane.tailscale.com/key?v=57
* Trying 18.156.90.224:443...
* Connected to controlplane.tailscale.com (18.156.90.224) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
i reinstalled tailscaled and deleted status file and the problem still persist.
I am trying to implement mTLS between two services. I am using hashicorp vault to manage certs (CA, clients and servers). After deploying the server using istio gateway with secret generated from respective certs. I am trying to access that server using curl. But I am getting the error:
#pemFiles is chain of root and intermediate CA
curl -vvv -HHost:<some-host> --resolve "<some-host>:443:<istio-gateway-ip>" --cacert pemFiles --cert client.crt --key client.key "https://<istio-gateway-ip>:443/" -Lk
* Added <some-host>:443:<istio-gateway-ip> to DNS cache
* Hostname <some-host> was found in DNS cache
* Trying <istio-gateway>:443...
* Connected to <some-host> (<istio-gateway-ip>) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: pemFiles
* CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Request CERT (13):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS handshake, CERT verify (15):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=5402476c-df7d-44bc-9c1b-b0a6afb931d7
* start date: Sep 23 21:28:29 2021 GMT
* expire date: Oct 25 21:28:58 2021 GMT
* issuer: CN=<our-domain>
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x293ec1a2fb0)
> GET / HTTP/2
> Host:<some-host>
> user-agent: curl/7.75.0
> accept: */*
>
* OpenSSL SSL_read: Connection was aborted, errno 10053
* Failed receiving HTTP2 data
* OpenSSL SSL_write: Connection was aborted, errno 10053
* Failed sending HTTP2 data
* Connection #0 to host <some-host> left intact
curl: (56) OpenSSL SSL_read: Connection was aborted, errno 10053
When I use the same steps with certs generated manually using OpenSSL, I am not getting any such issue.
When I pass the "--http2" with curl command:
TLSv1.3 (IN), TLS alert, unknown CA (560):
* OpenSSL SSL_read: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca, errno 0
* Failed receiving HTTP2 data
* OpenSSL SSL_write: SSL_ERROR_ZERO_RETURN, errno 0
* Failed sending HTTP2 data
* Connection #0 to host <some-host> left intact
curl: (56) OpenSSL SSL_read: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca, errno 0
A workaround found by OP, in the comments.
The issue was with OP's cert-manager. As a workaround use root CA cert instead of intermediate CA.
I have a machine serving sites under docker, reverse proxied through nginx with TLS. Everything went smooth til around April the 15th. Two sites became inaccessible from iPhone (whatever the browser used), Safari on MacBooks... curl, and old Android (Samsung S2) and old Firefox (v25)! :o Everything goes fine from Firefox on Windows, GNU/Linux.
One site is a Mattermost instance; the app is working correctly from Android but not from an iPhone.
Safari complains it "can't load the page, the conection has been lost".
curl -v mysite reports :
Rebuilt URL to: https://teamtime.me/
Hostname was NOT found in DNS cache
Trying 212.129.18.187...
Connected to teamtime.me (212.129.18.187) port 443 (#0)
successfully set certificate verify locations:
CAfile: none
CApath: /etc/ssl/certs
SSLv3, TLS handshake, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS handshake, Server key exchange (12):
SSLv3, TLS handshake, Server finished (14):
SSLv3, TLS handshake, Client key exchange (16):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSLv3, TLS change cipher, Client hello (1)
SSLv3, TLS handshake, Finished (20):
SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
Server certificate:
subject: CN=teamtime.me
start date: 2017-04-02 21:41:00 GMT
expire date: 2017-07-01 21:41:00 GMT
subjectAltName: teamtime.me matched
issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
SSL certificate verify ok.
GET / HTTP/1.1
User-Agent: curl/7.38.0
Host: teamtime.me
Accept: /
SSL read: error:00000000:lib(0):func(0):reason(0), errno 104
Closing connection 0
curl: (56) SSL read: error:00000000:lib(0):func(0):reason(0), errno 104
I sniffed the connection to the site with firefox and curl and noted the following differences:
With firefox, after the client key exchange, a new session ticket is created by the server and an application data packet of 320 in size is sent back to the server,
while with curl, after the client key exchange, the server sends a change cipher spec, the client answers with a packet application data of 170 in size which ends the conection (ACK then RST-ACK from the server).
I'm stuck here. I don't know where to look. I don't have any apple terminal to test with, but I guess the problem with curl has the same root as it occurred in the same time frame.
Any hint would be very appreciated. Thanks in advance.
differences in sniffing firefox and curl
The server is (was) also serving a #mastodon instance. And it happened that shutting down the mastodon instance solved the problem: curl and apple terminals can reach the other services again.
The problem surely lies in the nginx reverse proxy configuration, but don't know yet what...
I'd also be interested in understanding how a mistaken config of nginx affects only some terminals/browsers...
I am integrating PayPal Express Checkout in the Sandbox using SOAP XML. SetExpressCheckout was working properly using a signature for credentials on 9/18/2013. I made no changes to my code or to the web server. I did begin work on Callback using NVP, since no SOAP version of Callback is available. The next day, SetExpressCheckout stopped working. I now get the following error: "80072f0c A certificate is required to complete client authentication" when trying to post to https://api-3t.sandbox.paypal.com/2.0/
Question 1: Could trying to use NVP Callback have caused PayPal's API server to now require a client certificate rather that a signature?
Question 2: Is there some other explanation for this change in behavior?
Question 3: Should I remove the signature from my sandbox account and request an API certificate instead? (Despite PayPal's recommendation that signatures be used rather than certificates.)
Note: I have tried using my own sandbox signature as well as the generic, "always works", sandbox signature. I have also tried posting to both api-3t.sandbox.paypal.com/2.0/ and api.sandbox.paypal.com/2.0/ (without -3t). None of these efforts eliminated the error.
Thanks, Chris H
are you still seeing this issue?
I am unable to reproduce it even using the IP you got back from nslookup.
Here my test with 23.51.43.42. I'm having the same positive result with 23.50.75.42
curl \
-H "Host: api-3t.sandbox.paypal.com" \
-d "USER=guus_1192700083_biz_api1.paypal.com&PWD=XXXXXXXXXX&SIGNATURE=XXXXXXXXXX&VERSION=108&METHOD=SetExpressCheckout&RETURNURL=http://www.paypal.com&CANCELURL=http://www.paypal.com&AMT=0.01&PAYMENTACTION=Authorization" \
https://23.51.43.42/nvp -kv
* About to connect() to 23.51.43.42 port 443 (#0)
* Trying 23.51.43.42...
* 0x8001f188 is at send pipe head!
* STATE: CONNECT => WAITCONNECT handle 0x80057568; line 1032 (connection #0)
* Connected to 23.51.43.42 (23.51.43.42) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: /usr/ssl/certs/ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
* STATE: WAITCONNECT => PROTOCONNECT handle 0x80057568; line 1145 (connection #0)
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-SHA
* Server certificate:
* subject: C=US; ST=CALIFORNIA; L=San Jose; O=PayPal, Inc.; OU=Partner Support; CN=api-3t.sandbox.paypal.com
* start date: 2013-08-20 00:00:00 GMT
* expire date: 2015-08-21 23:59:59 GMT
* issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)10; CN=VeriSign Class 3 Secure Server CA - G3
* SSL certificate verify ok.
* STATE: PROTOCONNECT => DO handle 0x80057568; line 1164 (connection #0)
> POST /nvp HTTP/1.1
> User-Agent: curl/7.29.0
> Accept: */*
> Host: api-3t.sandbox.paypal.com
> Content-Length: 261
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 261 out of 261 bytes
* STATE: DO => DO_DONE handle 0x80057568; line 1236 (connection #0)
* STATE: DO_DONE => WAITPERFORM handle 0x80057568; line 1352 (connection #0)
* STATE: WAITPERFORM => PERFORM handle 0x80057568; line 1363 (connection #0)
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
< Server: Apache
< Content-Length: 133
< Content-Type: text/plain; charset=utf-8
< DC: origin2-api-3t.sandbox.paypal.com
< Date: Thu, 03 Oct 2013 20:07:10 GMT
< Connection: keep-alive
< Set-Cookie: DC=origin2-api-3t.sandbox.paypal.com; secure
<
* STATE: PERFORM => DONE handle 0x80057568; line 1533 (connection #0)
* Connection #0 to host 23.51.43.42 left intact
TOKEN=EC%2d03T72513NN7526924&TIMESTAMP=2013%2d10%2d03T20%3a07%3a10Z&CORRELATIONID=4776c1624af4e&ACK=Success&VERSION=108&BUILD=7920936
Two days ago, something broke with our paypal integration. Unfortunately, trying to contact paypal support has proven to be of no help (no reply in 2 days), so I'll try my luck, here.
Requesting the token (curl https://api.paypal.com/v1/oauth2/token -H "Accept: application/json" -H "Accept-Language: en_US" -u "****:****" -d "grant_type=client_credentials") started ALWAYS returning an empty response and well, a 500 error.
Note that the same works just fine with api.sandbox.paypal.com and sandbox credentials.
I double checked our credentials and they are fine. Note as well, that it doesn't matter what credentials I use, it always returns the same - 500.
Here's the output of curl ... -v; looks like you have an internal server error, as the 500 shows:
* About to connect() to api.paypal.com port 443 (#0)
* Trying 173.0.88.98...
* connected
* Connected to api.paypal.com (173.0.88.98) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: /usr/ssl/certs/ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DES-CBC3-SHA
* Server certificate:
* subject: C=US; ST=California; L=San Jose; O=PayPal, Inc.; OU=PayPal Production; CN=api.paypal.com
* start date: 201
* expire date: 201
* subjectAltName: api.paypal.com matched
* issuer: C=U
* SSL certificate verify ok.
* Server auth using Basic with user '****'
> POST /v1/oauth2/token HTTP/1.1
> Authorization: Basic ****
> User-Agent: curl/7.27.0
> Host: api.paypal.com
> Accept: application/json
> Accept-Language: en_US
> Content-Length: 29
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 29 out of 29 bytes
* additional stuff not fine /usr/src/ports/curl/curl-7.27.0-1/src/curl-7.27.0/lib/transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 500 Internal Server Error
< Server: Apache-Coyote/1.1
< Date: Thu, 28 Mar 2013 15:59:53 GMT
< Content-Length: 0
< Connection: close
<
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
Thanks!
This is something that is currently being looked into. If you have not already opened a ticket with PayPal MTS I would advise opening up a ticket with Technical Support, so that your issue can be added to the examples. You will also then be notified once the issue has been resolved.
edit: This is now resolved as of 04:12 AM GMT (31/03/2013).