I have a Tomcat app configured with Azure ADFS SSO over SAML. SSO is working, however I now need to access my Tomcat app via restful API with Azure ADFS SSO.
I was able to get access token from Azure AD SSO by doing
curl -X POST -d 'grant_type=client_credentials&client_id=<APP_ID>&client_secret=<PASSWORD>&resource=https%3A%2F%2Fmanagement.azure.com%2F' https://login.microsoftonline.com/<TENANT_ID>/oauth2/token | jq .
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1592 100 1420 100 172 3169 383 --:--:-- --:--:-- --:--:-- 3553
{
"token_type": "Bearer",
"expires_in": "3599",
"ext_expires_in": "3599",
"expires_on": "1592338746",
"not_before": "1592334846",
"resource": "https://management.azure.com/",
"access_token": "MY_TOKEN"
}
If I don't have SSO turn on, I would usually create seesion cookie in my Tomcat app doing this
curl -v -k -X POST 'https://<HOSTNAME>/<APP>/j_spring_security_check?j_username=<USERNAME>&j_password=<PASSWORD>' -c ./cookie.txt
I've tried passing token as header, but didn't work
curl -v -k -X POST 'https://<HOSTNAME>/<APP>/j_spring_security_check?j_username=<USERNAME>&j_password=<PASSWORD>' -c ./cookie.txt --header "Authorization: Bearer MY_TOKEN"
Cookie.txt created.
Then I tried to call a GET API, didn't get the expected response JSON, but here is the verbose log from curl.
curl -v -k -X GET 'https://<HOSTNAME>/<APP>/source/v1/getSources?type=EXTERNAL&count=2&sortAttr=name&sortDir=ASC' -b ./cookie.txt | jq .
Note: Unnecessary use of -X or --request, GET is already inferred.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:04 --:--:-- 0* Trying 192.168.56.210...
* TCP_NODELAY set
0 0 0 0 0 0 0 0 --:--:-- 0:00:05 --:--:-- 0* Connected to HOSTNAME> (192.168.56.210) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [223 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [81 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [859 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=blah; ST=us; L=us; O=blah; OU=blah; CN=blah
* start date: Jun 16 14:21:29 2020 GMT
* expire date: Sep 14 14:21:29 2020 GMT
* issuer: C=blah; ST=us; L=us; O=blah; OU=blah; CN=blah
* SSL certificate verify result: self signed certificate (18), continuing anyway.
> GET /qdc/source/v1/getSources?type=EXTERNAL&count=2&sortAttr=name&sortDir=ASC HTTP/1.1
> Host: dfz.local:8443
> User-Agent: curl/7.64.1
> Accept: */*
> Cookie: JSESSIONID=1D244E5E4DBA30399E856E01909B0DDF
>
< HTTP/1.1 302 Found
< Server: Apache-Coyote/1.1
< Cache-control: no-cache, no-store
< Pragma: no-cache
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Strict-Transport-Security: max-age=31536000 ; includeSubDomains
< Location: https://login.microsoftonline.com/f08ee33a-102b-4180-998b-3fdd8acc49ab/saml2?SAMLRequest=hZLNTsMwEIRfxdp7EseJwLGaogJCIIGoSODAzXGc1lViF69TIZ6e0B8BFzhantnxzufZxfvQk532aJwtIY0pEG2Va41dlfBc30QcLuYzlEPPtmIxhrV90m%2BjxkAmo0VxuClh9FY4iQaFlYNGEZSoFg%2F3gsVUbL0LTrkeyAJR%2BzBFXTmL46B9pf3OKP38dF%2FCOoQtiiRpu4%2B4d0r2gud5lry1KvlKSarqEcj1FG2sDPvnnhy9WxkbD0Z5h64LzvbG6li5Ieko1zrLZJRS1kR5ymlUFLyJsq5tuVQqL2Szn86A3Div9H7FEjrZowZyd12C5Oema7rNmVkVWdqwRm1yzlKzWVNTZJMGlxLR7PS3C3HUdxaDtKEERhmN6FmU8pqlIqOC8pin2SuQ5bGXS2MPff9VYnMQobit62W0fKxqIC8nbpMAjpTEPt3%2FxPP3YHliAvP%2FCAw6yFYGOUt%2BRs2Px9%2F%2FY%2F4J&SigAlg=http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-sha1&Signature=HcbOW7%2BIOjXNr73H%2BKRHEtIbjJGPHa5CsXCeoSzVMVf5lCu07AEtpVPZmVw9IViBZcniKqhnC2zokz6ZOtVehsuNcSLDWpqViLLRicqBtRenmfe9RL5vI%2BlpcdS92wRT44V%2FMH1t3y7lILea34sLP2ySz0XVORSxL7FzEade3Q72cHQyu1xBuFlf9x7BUjxe8ZO5rZeGFsq98AQ9IwZIlJ3%2Fs%2F8Kp3eexw%2BmfVRhLU7eNLefDX%2BMfux%2BHvlKVlQpI6iHR1LSIEcNXX6nV%2BEAt7oa20FBDXV0PSGBy8hcBgzyPLhwFMWhe5%2BzUt9ssL2IO9kk8loWBNQek6x%2Bmpzw5w%3D%3D
< Content-Length: 0
< Date: Thu, 18 Jun 2020 21:30:08 GMT
<
0 0 0 0 0 0 0 0 --:--:-- 0:00:05 --:--:-- 0
* Connection #0 to host dfz.local left intact
* Closing connection 0
Curl for client credential grant type
curl -X POST -d “grant_type=client_credentials&client_id=clientid&client_secret= secret&scope= https%3A%2F%2Fgraph.microsoft.com%2F.default” https://login.microsoftonline.com/tenantid/oauth2/v2.0/token
After getting the token use below query to pass the token in header
curl -H "Authorization: Basic <_your_token_>" http://www.example.com
Related
Here is the source URL of the image -
https://erp.guu-portal.de/erp/dokumente/download/759927?filename=9783835408241.jpg
curl result for the image file -
curl -v 'https://erp.guu-portal.de/erp/dokumente/download/759927?filename=9783835408241.jpg'
* Trying 62.245.203.125:443...
* Connected to erp.guu-portal.de (62.245.203.125) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
* CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=*.guu-portal.de
* start date: Jan 5 00:00:00 2021 GMT
* expire date: Feb 5 23:59:59 2022 GMT
* subjectAltName: host "erp.guu-portal.de" matched cert's "*.guu-portal.de"
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA
* SSL certificate verify ok.
> GET /erp/dokumente/download/759927?filename=9783835408241.jpg HTTP/1.1
> Host: erp.guu-portal.de
> User-Agent: curl/7.77.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Fri, 14 Jan 2022 17:55:16 GMT
< Server: Apache-Coyote/1.1
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< X-Frame-Options: SAMEORIGIN
< Last-Modified: Thu, 18 Oct 2018 20:32:21 GMT
< Content-Disposition: attachment; filename=9783835408241.jpg
< Content-Type: image/jpeg;charset=UTF-8
< Content-Length: 182163
< Set-Cookie: JSESSIONID=30BDB73806080AEF778934ABEBADFFCE.worker1; Path=/erp; HttpOnly
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failure writing output to destination
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, close notify (256):
I was sending payload in post request -
payload = {'image': {'src': 'https://erp.guu-portal.de/erp/dokumente/download/759927?filename=9783835408241.jpg', 'filename': '399_1.jpg'}}
Posting images to rest API URL -
requests.session.put(base_url + f"products/{product_id}.json",payload))
Response:
Status Code 422 with Message: {"errors":{"image":["Could not process image: [\"\/erp\/dokumente\/download\/759927 (image\/jpeg;charset=UTF-8) is not a recognized format\"]"]}}
I have tried other public images and they work... however, they had content-type image/jpeg only
I'm having trouble getting an WSDL file via cURL. I think it has to be related to the cURL version. The command is working in a Docker image based on Debian 9, cURL version:
# curl --version
curl 7.52.1 (x86_64-pc-linux-gnu) libcurl/7.52.1 OpenSSL/1.0.2l zlib/1.2.8 libidn2/0.16 libpsl/0.17.0 (+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
However, the baseimage was updated to Debian 10 and there the command is not running. cURL Version:
# curl --version
curl 7.64.0 (x86_64-pc-linux-gnu) libcurl/7.64.0 OpenSSL/1.1.1d zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 librtmp/2.3
Release-Date: 2019-02-06
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
I can download the WSDL with wget or with an browser but I need cURL for this command. I found this answer and I tried the cURL command copied from Chromium but get the same result...
The command:
# curl -vvv -k --header "Authorization: Basic <B64Encoded>" https://IP/service.asmx?WSDL -o /dev/null
outputs on debian 9 (cURL 7.52.1):
* Trying IP...
* TCP_NODELAY set
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to IP (IP) port 443 (#0)
* ALPN, offering h2
* 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):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [81 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [753 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: CN=WMSvc-VS47558B
* start date: Sep 5 11:51:31 2016 GMT
* expire date: Sep 3 11:51:31 2026 GMT
* issuer: CN=WMSvc-VS47558B
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
} [5 bytes data]
> GET /service.asmx?WSDL HTTP/1.1
> Host: IP
> User-Agent: curl/7.52.1
> Accept: */*
> Authorization: Basic RUNTOnA5NDEtRUNTMjAyMQ==
>
{ [5 bytes data]
< HTTP/1.1 200 OK
< Cache-Control: private, max-age=0
< Content-Type: text/xml; charset=utf-8
< Server: Microsoft-IIS/8.5
< X-AspNet-Version: 4.0.30319
< X-Powered-By: ASP.NET
< Date: Fri, 12 Mar 2021 21:41:16 GMT
< Content-Length: 243498
<
{ [16151 bytes data]
* Curl_http_done: called premature == 0
100 237k 100 237k 0 0 2083k 0 --:--:-- --:--:-- --:--:-- 2104k
* Connection #0 to host IP left intact
* List item
and on Debian 10 (cURL 7.64.0)
* Expire in 0 ms for 6 (transfer 0x5555fcd9df50)
* Trying IP...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5555fcd9df50)
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to IP (IP) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to IP:443
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to IP:443
Does it something have to do with the ca-certs?
On Debian 10 this package is installed: ca-certificates/now 20200601~deb10u1 all [installed,local]
On Debian 9 ca-certs is not installed
Forcing a TLS Version below 1.3 gives the same result. The remote server is a Windows Server 2012, I think they are using just outdated ciphers or something. But how can I proove that and is there a workaround? In the cURL changelogs I didn't find a change like 'drop support for....' or something.
Here is the tutorial that I am following: What is the best way to enable a website users send money to each other?
The problem is with my post request.
Let's break it down into pieces.
Headers
headers: {
"Authorization": `Bearer ${accessToken}`,
"Content-Type": "application/json"
}
I get the access token also via paypal api namely https://api.sandbox.paypal.com/v1/oauth2/token.
Body
body: {
intent: 'CAPTURE',
purchase_units: [{
amount: {
currency_code: 'USD',
value: '2.00'
},
payee: {
email_address: "myanothersandboxaccount#gmail.com"
}
}]
}
But, it doesn't work, as I get an error
{
name: 'INVALID_REQUEST',
message: 'Request is not well-formed, syntactically incorrect, or violates schema.',
debug_id: '2884e1b5eccee',
details: [
{
field: '/',
location: 'body',
issue: 'INVALID_SYNTAX',
description: 'MALFORMED_REQUEST_JSON'
}
],
links: [
{
href: 'https://developer.paypal.com/docs/api/orders/v2/#error-INVALID_SYNTAX',
rel: 'information_link',
encType: 'application/json'
}
]
}
curl request
curl -v -X POST https://api.sandbox.paypal.com/v2/checkout/orders \
-H "Content-Type: application/json" \
-H "Authorization: Bearer A23AALAej8Yg-4iKJBcWckiv5-ZlhYWlkmBsPuWaVngJcMigU7P-6f8P02vnOpIo8QlOJ-P3hd3K86vKo_lpSlu0-bZBj98eg" \
-d '{
"intent": "CAPTURE",
"purchase_units": [
{
"amount": {
"currency_code": "USD",
"value": "100.00"
},
"payee": {
"email": "myanothersandboxaccount#gmail.com"
}
}
]
}'
curl response
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 173.0.82.78...
* TCP_NODELAY set
* Connected to api.sandbox.paypal.com (173.0.82.78) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; ST=California; L=San Jose; O=PayPal, Inc.; OU=PayPal Production; CN=api.sandbox.paypal.com
* start date: Jul 27 00:00:00 2020 GMT
* expire date: Aug 1 12:00:00 2022 GMT
* subjectAltName: host "api.sandbox.paypal.com" matched cert's "api.sandbox.paypal.com"
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
* SSL certificate verify ok.
> POST /v2/checkout/orders HTTP/1.1
> Host: api.sandbox.paypal.com
> User-Agent: curl/7.64.1
> Accept: */*
> Content-Type: application/json
> Authorization: Bearer A23AALAej8Yg-4iKJBcWckiv5-ZlhYWlkmBsPuWaVngJcMigU7P-6f8P02vnOpIo8QlOJ-P3hd3K86vKo_lpSlu0-bZBj98eg
> Content-Length: 212
>
* upload completely sent off: 212 out of 212 bytes
< HTTP/1.1 201 Created
< Cache-Control: max-age=0, no-cache, no-store, must-revalidate
< Content-Length: 501
< Content-Type: application/json
< Date: Sat, 05 Dec 2020 10:30:13 GMT
< Paypal-Debug-Id: 6bd069526af1c
<
* Connection #0 to host api.sandbox.paypal.com left intact
{"id":"674004650C383744Y","status":"CREATED","links":[{"href":"https://api.sandbox.paypal.com/v2/checkout/orders/674004650C383744Y","rel":"self","method":"GET"},{"href":"https://www.sandbox.paypal.com/checkoutnow?token=674004650C383744Y","rel":"approve","method":"GET"},{"href":"https://api.sandbox.paypal.com/v2/checkout/orders/674004650C383744Y","rel":"update","method":"PATCH"},{"href":"https://api.sandbox.paypal.com/v2/checkout/orders/674004650C383744Y/capture","rel":"capture","method":"POST"}]}* Closing connection 0
And, with curl I get a successful response. I can see that all went well from my paypal sandbox dashboard.
What could it be?
I was using node-fetch to call the paypal api to create an order. Tried with axios, worked just fine.
The error basically means PayPal isn't able to parse the body object it received as JSON, so it appears something is being transmitted/received incorrectly.
You should first test with command-line curl to verify functionality and your JSON's correctness, which should work.
Then to get more details about what's actually going wrong in what you are sending, you will need to log the actual data being sent (not your code, the actual data the code sends when executed)
One way to do this is to instead of sending your request to https://api-m.paypal.com , instead send it to a request bin service like offered via https://requestbin.com/
I have a node:8.9.2-alpine image where I try to run
curl -o /dev/null -s -w 'Total: %{time_total}\n' 'https://feed.theplatform.com/' -v
The call takes 6 sec. If I run the same curl locally it takes like 0.5 sec.
I found out that nslookup takes some time, so I ran
RUN apk add --update --no-cache bind-tools
however my curl still takes 6 sec.
/ # curl -o /dev/null -s -w 'Total: %{time_total}\n' 'https://feed.theplatform.com/' -v --trace-time
10:13:54.843110 * Trying 199.27.170.188...
10:13:54.843198 * TCP_NODELAY set
10:13:54.938974 * Connected to feed.theplatform.com (199.27.170.188) port 443 (#0)
10:13:54.939222 * ALPN, offering http/1.1
10:13:54.950969 * successfully set certificate verify locations:
10:13:54.951041 * CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: none
10:13:54.951198 * TLSv1.2 (OUT), TLS handshake, Client hello (1):
10:13:54.951222 } [512 bytes data]
10:13:55.046650 * TLSv1.2 (IN), TLS handshake, Server hello (2):
10:13:55.046875 { [85 bytes data]
10:13:55.047031 * TLSv1.2 (IN), TLS handshake, Certificate (11):
10:13:55.047063 { [3984 bytes data]
10:13:55.047965 * TLSv1.2 (IN), TLS handshake, Server finished (14):
10:13:55.047990 { [4 bytes data]
10:13:55.048175 * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
10:13:55.048197 } [262 bytes data]
10:13:55.048233 * TLSv1.2 (OUT), TLS change cipher, Client hello (1):
10:13:55.048253 } [1 bytes data]
10:13:55.048338 * TLSv1.2 (OUT), TLS handshake, Finished (20):
10:13:55.048358 } [16 bytes data]
10:13:55.147028 * TLSv1.2 (IN), TLS change cipher, Client hello (1):
10:13:55.147077 { [1 bytes data]
10:13:55.147205 * TLSv1.2 (IN), TLS handshake, Finished (20):
10:13:55.147227 { [16 bytes data]
10:13:55.147273 * SSL connection using TLSv1.2 / AES256-SHA256
10:13:55.147295 * ALPN, server did not agree to a protocol
10:13:55.147339 * Server certificate:
10:13:55.147395 * subject: C=US; ST=Washington; L=Seattle; O=thePlatform, LLC; OU=Network Operations; CN=feed.theplatform.com
10:13:55.147423 * start date: Oct 22 22:05:39 2015 GMT
10:13:55.147451 * expire date: Jan 5 22:35:38 2019 GMT
10:13:55.147495 * subjectAltName: host "feed.theplatform.com" matched cert's "feed.theplatform.com"
10:13:55.147531 * issuer: C=US; O=Entrust, Inc.; OU=See www.entrust.net/legal-terms; OU=(c) 2012 Entrust, Inc. - for authorized use only; CN=Entrust Certification Authority -L1K
10:13:55.147553 * SSL certificate verify ok.
10:13:55.147650 > GET / HTTP/1.1
10:13:55.147650 > Host: feed.theplatform.com
10:13:55.147650 > User-Agent: curl/7.60.0
10:13:55.147650 > Accept: */*
10:13:55.147650 >
10:13:55.244488 < HTTP/1.1 403 Forbidden
10:13:55.244544 < Date: Fri, 13 Jul 2018 10:13:55 GMT
10:13:55.244576 < Content-Type: text/html;charset=ISO-8859-1
10:13:55.244606 < Cache-Control: must-revalidate,no-cache,no-store
10:13:55.244637 < Content-Length: 1365
10:13:55.244668 < Connection: close
10:13:55.244699 < Server: Jetty(8.1.16.2)
10:13:55.244730 <
10:13:55.244760 { [1225 bytes data]
10:13:55.244901 * Closing connection 0
10:13:55.245043 * TLSv1.2 (OUT), TLS alert, Client hello (1):
10:13:55.245079 } [2 bytes data]
Total: 5.915162
enter code here
enter code here
If I call the http version it still takes too long time:
/ # curl -o /dev/null -s -w 'Total: %{time_total}\n' 'http://feed.theplatform.com/' -v --trace-time
10:12:29.865144 * Trying 199.27.170.188...
10:12:29.865215 * TCP_NODELAY set
10:12:29.961021 * Connected to feed.theplatform.com (199.27.170.188) port 80 (#0)
10:12:29.961119 > GET / HTTP/1.1
10:12:29.961119 > Host: feed.theplatform.com
10:12:29.961119 > User-Agent: curl/7.60.0
10:12:29.961119 > Accept: */*
10:12:29.961119 >
10:12:30.057339 < HTTP/1.1 403 Forbidden
10:12:30.057395 < Date: Fri, 13 Jul 2018 10:12:30 GMT
10:12:30.057425 < Content-Type: text/html;charset=ISO-8859-1
10:12:30.057453 < Cache-Control: must-revalidate,no-cache,no-store
10:12:30.057482 < Content-Length: 1365
10:12:30.057505 < Connection: close
10:12:30.057527 < Server: Jetty(8.1.16.2)
10:12:30.057554 <
10:12:30.057578 { [1365 bytes data]
10:12:30.057666 * Closing connection 0
Total: 5.705922
I have the same issue if I use node:8.11.3-alpine
As the time shows, it is the start of the call that has an issue.
How do I fix this?
It was an issue with my name server.
By adding %{time_namelookup} and running
curl -o /dev/null -s -w 'Total: %{time_total}\nTime Namelookup: %{time_namelookup}\n' 'http://feed.theplatform.com/' -v --trace-time
I got Time Namelookup: 5.514205
I tried changing the nameserver to googles and then I got the result in 0.5 sec.
I am trying to access a remote server which responds properly in one network but not in another. I can access it on my local machine(In some networks) but not on aws:
Working Curl:
curl -vvv https://abc.example.com -H 'Content-Type:text/xml' --user ******:***** -d '<XML></XML>'
Output:
* Hostname was NOT found in DNS cache
* Trying xx.xx.xx.xx...
* Connected to abc.example.com (xx.xx.xx.xx) 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: C=**; ST=***; L=***; x.x.x.x.x.x.x.x.x.x=**; x.x.x.x.x.x.x.x.x.x=ABCD; x.x.x.x.x.x.x.x.x.x.x=def; O=abc def ghi; businessCategory=abc def; serialNumber=123456; CN=abc.example.com
* start date: 2016-04-04 07:19:41 GMT
* expire date: 2018-04-04 07:49:39 GMT
* subjectAltName: abc.example.com matched
* issuer: C=US; O=Entrust, Inc.; OU=See www.entrust.net/legal-terms; OU=(c) 2014 Entrust, Inc. - for authorized use only; CN=Entrust Certification Authority - L1M
* SSL certificate verify ok.
* Server auth using Basic with user '******'
> POST /abc/def HTTP/1.1
> Authorization: Basic *********************
> User-Agent: curl/7.38.0
> Host: abc.example.com
> Accept: */*
> Content-Type:text/xml
> Content-Length: 16783
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
< Date: Sat, 23 Apr 2016 07:31:25 GMT
* Server Oracle-Application-Server-11g is not blacklisted
< Server: Oracle-Application-Server-11g
< X-ORACLE-DMS-ECID: *************************
< SOAPAction: "http://ghi.services//abc"
< X-Powered-By: Servlet/2.5 JSP/2.1
< Vary: Accept-Encoding,User-Agent
< Content-Type: text/xml; charset=utf-8
< Content-Language: en
< Transfer-Encoding: chunked
<
<XML>SUCCESSFUL OUTPUT</XML>
Not working CURL:
curl -vvv https://abc.example.com -H 'Content-Type:text/xml' --user ******:***** -d '<XML></XML>'
Output:
* Hostname was NOT found in DNS cache
* Trying xx.xx.xx.xx...
* Connected to abc.example.com (xx.xx.xx.xx) 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 ECDHE-RSA-AES256-GCM-SHA384
* Server certificate:
* subject: C=XX; ST=XXXXXXX; L=XXXXXXX; x.x.x.x.x.x.x=XX; x.x.x.x.x.x.x=XXXXXXX; x.x.x.x.x.x.x.x.x.x.x.x=XXXXX; O=Some company name; businessCategory=My unit; serialNumber=12345; CN=abc.example.com
* start date: 2016-04-04 07:19:41 GMT
* expire date: 2018-04-04 07:49:39 GMT
* subjectAltName: abc.example.com matched
* issuer: C=US; O=Entrust, Inc.; OU=See www.entrust.net/legal-terms; OU=(c) 2014 Entrust, Inc. - for authorized use only; CN=Entrust Certification Authority - L1M
* SSL certificate verify ok.
* Server auth using Basic with user '**********'
> POST /abc/def HTTP/1.1
> Authorization: Basic ******************
> User-Agent: curl/7.35.0
> Host: abc.example.com
> Accept: */*
> Content-Type:text/xml
> Content-Length: 16783
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
< HTTP/1.1 400 Bad Request
< Date: Sat, 23 Apr 2016 07:37:47 GMT
* Server Apache is not blacklisted
< Server: Apache
< Content-Length: 226
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>
* Closing connection 0
* SSLv3, TLS alert, Client hello (1):
I don't have any idea what's going on. Please help