I am using curl command to get a webpage. But sometimes it doesn't give the response output. My curl command is that
[root#panzhengyu ~]# curl https://nn.cbcb.us/register.php
[root#panzhengyu ~]# curl https://nn.cbcb.us/register.php
[root#panzhengyu ~]# curl https://nn.cbcb.us/register.php
[root#panzhengyu ~]# curl https://nn.cbcb.us/register.php
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gbk">
<title>²ށ^ - t66y.com</title>
<meta name="keywords" content="²ށ24,²ށ^,1024app,²ށ𠯰,С²ܡpp,מo´a,מԐ´a,WĀo´a,Ԃþo´a,݄؎½»·,¼¼ϧӑՓ^,ޟȷ µņ쏃,тr´,³ʈ̎ČW,՚¾³ʈ̓°Ժ,httpЂܤ,²ށD,²ށ,t66y.com" />
<meta name="description" content="²ށ^ t66y.com" />
<base href="https://nn.cbcb.us/" />
<link rel="stylesheet" href="//www.viidii.info/web/style.css?v=2.0253" type="text/css" />
</head><body>
<div id="header">
<div class="banner" style="padding-left:5px;"><FONT SIZE="7" COLOR="white"><B>²ށ^</B></FONT></div>
<div class="h guide" colspan="2">»
I have tried four times. But the First three times don't have output. I don't know why happens this?
my curl version is
[root#panzhengyu ~]# curl --version
curl 7.61.1 (x86_64-redhat-linux-gnu) libcurl/7.61.1 OpenSSL/1.0.1e zlib/1.2.3 c-ares/1.14.0 libssh2/1.8.0 nghttp2/1.6.0
Release-Date: 2018-09-05
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz HTTP2 UnixSockets HTTPS-proxy Metalink
[root#panzhengyu ~]#
the following is the log of "curl -v https://nn.cbcb.us/register.php", directly output to stderr.
curl -v https://nn.cbcb.us/register.php
* Trying 2606:4700:30::681b:b329...
* TCP_NODELAY set
* Connected to nn.cbcb.us (2606:4700:30::681b:b329) port 443 (#0)
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* NPN, negotiated HTTP2 (h2)
* 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, Next protocol (67):
* 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-ECDSA-AES128-GCM-SHA256
* Server certificate:
* subject: OU=Domain Control Validated; OU=PositiveSSL Multi-Domain; CN=sni133140.cloudflaressl.com
* start date: Jun 8 00:00:00 2018 GMT
* expire date: Dec 15 23:59:59 2018 GMT
* subjectAltName: host "nn.cbcb.us" matched cert's "*.cbcb.us"
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO ECC Domain Validation Secure Server CA 2
* 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 0xf110e0)
> GET /register.php HTTP/2^M
> Host: nn.cbcb.us^M
> User-Agent: curl/7.61.1^M
> Accept: */*^M
> ^M
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 200 ^M
< date: Tue, 23 Oct 2018 06:05:30 GMT^M
< content-type: text/html^M
< set-cookie: __cfduid=d324f19ad0265d40a531c2d0fee4b8ff61540274730; expires=Wed, 23-Oct-19 06:05:30 GMT; path=/; domain=.cbcb.us; HttpOnly; Secure^M
< x-powered-by: PHP/5.6.33^M
< vary: Accept-Encoding^M
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"^M
< server: cloudflare^M
< cf-ray: 46e20329f9c478e6-LAX^M
< ^M
* Connection #0 to host nn.cbcb.us left intact
Try this to check logs of Curl. You will get more information:
Here is the command
curl -v 'https://nn.cbcb.us/register.php' >> test.logs
Source: https://www.unix.com/shell-programming-and-scripting/252609-curl-v-logs.html
Related
Recently we've added more users to our system and although the bandwidth usage is still in normal bounds and and server response is in normal bounds (after the tls handshake), the tls handshake can take between 1 and 2.5 seconds. Here the time between client hello and server hello was 1.5 seconds:
13:01:49.599739 * TLSv1.3 (OUT), TLS handshake, Client hello (1):
13:01:51.023274 * TLSv1.3 (IN), TLS handshake, Server hello (2):
We're running nodejs 16 with greenlock-express (I don't think that express or greenlock has anything to do with the handshake). Anyone have any ideas on how to find what's causing slow handshake? I noticed that after pm2 restart on the process the handshake is quick (at first), but I don't have any ideas as to why this should be:
13:20:24.977793 * TLSv1.3 (OUT), TLS handshake, Client hello (1):
13:20:25.063494 * TLSv1.3 (IN), TLS handshake, Server hello (2):
If we look at the whole log besides the delay between client and server hello - things are running smoothly.
:~$ curl -iv --trace-time https://{server name}
13:01:49.496453 * Rebuilt URL to: https://{server name}/
13:01:49.500927 * Trying 54.73.36.16...
13:01:49.500970 * TCP_NODELAY set
13:01:49.583976 * Connected to {server name} (54.73.36.16) port 443 (#0)
13:01:49.585712 * ALPN, offering h2
13:01:49.585791 * ALPN, offering http/1.1
13:01:49.599251 * successfully set certificate verify locations:
13:01:49.599324 * CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
13:01:49.599739 * TLSv1.3 (OUT), TLS handshake, Client hello (1):
13:01:51.023274 * TLSv1.3 (IN), TLS handshake, Server hello (2):
13:01:51.023566 * TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
13:01:51.023602 * TLSv1.3 (IN), TLS handshake, Unknown (8):
13:01:51.023679 * TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
13:01:51.023764 * TLSv1.3 (IN), TLS handshake, Certificate (11):
13:01:51.024257 * TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
13:01:51.024312 * TLSv1.3 (IN), TLS handshake, CERT verify (15):
13:01:51.024439 * TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
13:01:51.024504 * TLSv1.3 (IN), TLS handshake, Finished (20):
13:01:51.024599 * TLSv1.3 (OUT), TLS change cipher, Client hello (1):
13:01:51.024708 * TLSv1.3 (OUT), TLS Unknown, Certificate Status (22):
13:01:51.024785 * TLSv1.3 (OUT), TLS handshake, Finished (20):
13:01:51.024902 * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
13:01:51.024957 * ALPN, server accepted to use http/1.1
13:01:51.025023 * Server certificate:
13:01:51.025089 * subject: CN={server name}
13:01:51.025143 * start date: Oct 10 07:55:03 2022 GMT
13:01:51.025205 * expire date: Jan 8 07:55:02 2023 GMT
13:01:51.025273 * subjectAltName: host "{server name}" matched cert's "{server name}"
13:01:51.025341 * issuer: C=US; O=Let's Encrypt; CN=R3
13:01:51.025402 * SSL certificate verify ok.
13:01:51.025490 * TLSv1.3 (OUT), TLS Unknown, Unknown (23):
13:01:51.025584 > GET / HTTP/1.1
13:01:51.025584 > Host: {server name}
13:01:51.025584 > User-Agent: curl/7.58.0
13:01:51.025584 > Accept: */*
13:01:51.025584 >
13:01:51.139620 * TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
13:01:51.139776 * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
13:01:51.139981 * TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
13:01:51.140130 * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
13:01:51.221629 * TLSv1.3 (IN), TLS Unknown, Unknown (23):
13:01:51.221752 < HTTP/1.1 200 OK
HTTP/1.1 200 OK
13:01:51.221934 < X-Powered-By: Express
X-Powered-By: Express
13:01:51.222112 < Vary: Origin
Vary: Origin
13:01:51.222265 < Accept-Ranges: bytes
Accept-Ranges: bytes
13:01:51.222428 < Cache-Control: public, max-age=0
Cache-Control: public, max-age=0
13:01:51.222564 < Last-Modified: Sun, 13 Nov 2022 13:14:39 GMT
Last-Modified: Sun, 13 Nov 2022 13:14:39 GMT
13:01:51.222687 < ETag: W/"403-1847120b218"
ETag: W/"403-1847120b218"
13:01:51.222811 < Content-Type: text/html; charset=UTF-8
Content-Type: text/html; charset=UTF-8
13:01:51.222946 < Content-Length: 1027
Content-Length: 1027
13:01:51.223068 < Set-Cookie: connect.sid=s%3AD0KBzxmVDIb8vYcBmtdTZ6bvRF17NT1Q.1c6pkFHEoNWHl%2F4OT6bqMkm1csE; Path=/; HttpOnly
Set-Cookie: connect.sid=s%3AD0KBzxmVDIb8vYcBmtdTZ6bvRF17NT1Q.1c6pkFHEoNWbqMkm1csE; Path=/; HttpOnly
13:01:51.223192 < Date: Tue, 22 Nov 2022 11:01:50 GMT
Date: Tue, 22 Nov 2022 11:01:50 GMT
13:01:51.223316 < Connection: keep-alive
Connection: keep-alive
13:01:51.223439 < Keep-Alive: timeout=5
Keep-Alive: timeout=5
13:01:51.223567 <
<!doctype html>
In the end there was no problem with the tls handshake...
Our problem was because of a large session database. The session manager demanded a lot of cpu for this (which stole the cpu away from other things like crypto).
We noticed this when running the a cpu profile in the chrome dev tools while running the server in --inspect. I decided to answer this question instead of deleting in case someone else comes cross the same thing. If you come across a problem in the tls handshake - then take a look at what's grabbing the cpu. In our case after we cleared out the session database, the handshake became consistently quick.
How to publish apim developer portal using rest api calls throw a shell script or using this repo https://github.com/Azure/api-management-developer-portal/tree/master/scripts.v3
Method-1
Got a hint from this link
https://stackoverflow.com/questions/63796030/powershell-script-to-publish-apim-developer-portal
I tried with curl with the below request but was getting a 401 response.
curl -v -X POST apim-instance1.developer.azure-api.net/publish -H "Authorization: SharedAccessSignature <SAS token> " -H "Content-Length: 0"
Below is the response
* Trying 52.224.143.217...
* TCP_NODELAY set
* Connected to apim-instance1.developer.azure-api.net (52.224.143.217) 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.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, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; ST=WA; L=Redmond; O=Microsoft Corporation; CN=*.azure-api.net
* start date: May 27 03:02:35 2021 GMT
* expire date: May 22 03:02:35 2022 GMT
* subjectAltName: host "apim-instance1.developer.azure-api.net" matched cert's "*.developer.azure-api.net"
* issuer: C=US; O=Microsoft Corporation; CN=Microsoft Azure TLS Issuing CA 02
* SSL certificate verify ok.
> POST /publish HTTP/1.1
> Host: apim-instance1.developer.azure-api.net
> User-Agent: curl/7.58.0
> Accept: */*
> Authorization: SharedAccessSignature ?sv=2020-08-04&ss=bfqt&srt=sco&sp=rwdlacuptfx&se=2021-08-16T18:31:43Z&st=2021-08-16T10:31:43Z&spr=https&sig=DH24e2dYqDRJtpmTDI%2FkXGt2p3Gt1P33YFvIOPDasB8%3D
> Content-Length: 0
>
< HTTP/1.1 401 Unauthorized
< Keep-Alive: timeout=5
< Content-Type: application/json; charset=utf-8
< ETag: W/"61-pSa4Ze4sjk2JIS8YUgBXS7akHjk"
< X-Powered-By: Express
< X-Content-Type-Options: nosniff
< X-Frame-Options: sameorigin
< X-XSS-Protection: 1; mode=block
< Access-Control-Allow-Origin: *
< Strict-Transport-Security: max-age=31536000;includeSubDomains;
< Date: Mon, 16 Aug 2021 11:05:27 GMT
< Content-Length: 97
<
* Connection #0 to host apim-instance1.developer.azure-api.net left intact
{"code":"Unauthorized","message":"Please ensure that Authorization header contains valid token."}
What should be the right access token to use with this bash command and where to get it from?
Method-2
Using this repo https://github.com/Azure/api-management-developer-portal/tree/master/scripts.v3, passing required values and running ./generate.sh I get below error or response
Going to upload the content in /home/devops/Downloads/api-management-developer-portal/dist/snapshot.
Importing...
Unable to complete import. Unable to upload media files. mime.getType is not a function
How can we publish apim developer portal using rest api calls throw a shell script or this
(https://github.com/Azure/api-management-developer-portal/tree/master/scripts.v3) nodejs repo scripts.
Can anyone help me over here
Method 3
Use ARM revisions API: https://learn.microsoft.com/en-us/rest/api/apimanagement/2021-01-01-preview/portal-revision/create-or-update
when loading the embed.js from Instagram (https://www.instagram.com/embed.js) the returned redirect contains a strange redirect URL (duplicate //www.instagram.com). This only occurs if I'm working on a mobile network (tested with T-Mobile and Vodafone Germany). It's fine at home with the DSL line.
curl -v4 https://www.instagram.com/embed.js
* Trying 31.13.92.174...
* TCP_NODELAY set
* Connected to www.instagram.com (127.0.0.1) 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/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, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=CA; L=Menlo Park; O=Facebook, Inc.; CN=*.www.instagram.com
* start date: May 27 00:00:00 2019 GMT
* expire date: Aug 25 12:00:00 2019 GMT
* subjectAltName: host "www.instagram.com" matched cert's "www.instagram.com"
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
* 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 0x7f8fc2007a00)
> GET /embed.js HTTP/2
> Host: www.instagram.com
> User-Agent: curl/7.54.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 302
< content-type: text/html; charset=utf-8
< location: https://www.instagram.com//www.instagram.com/static/bundles/metro/EmbedSDK.js/43531caab721.js
< cache-control: max-age=21600
< date: Fri, 12 Jul 2019 07:52:30 GMT
< x-fb-trip-id: 1679558926
<
* Connection #0 to host www.instagram.com left intact
I tried different HTTP versions but that didn't help. I recognized it first in a browser where the Instagram embeds didn't work when loading the page from a mobile network.
I guess I'm doing something wrong when embedding Instagram but I think I implemented the embed according to their documentation.
Can someone give me a hint?
Many thanks!
I have created a basic script which checks for an email in my inbox, and yesterday everything was working fine. But today all i get is a HTTP404 when I run the same code.
I suspect that outlook.office365.com might be throttling my requests since I ran this 1 time every minute for about 36 hours. But how can i tell if that is the case?
Here are my curl command:
curl https://outlook.office365.com/api/1.0/Me/folders/Inbox/messages -u login#email.outlook:password --insecure --show-error -H Content-Type:application/json -v
and the output:
* About to connect() to outlook.office365.com port 443 (#0)
* Trying 132.245.48.18... connected
* Connected to outlook.office365.com (132.245.48.18) 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 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 AES256-SHA
* Server certificate:
* subject: C=US; ST=WA; L=Redmond; O=Microsoft Corporation; OU=Microsoft Corporation; CN=outlook.com
* start date: 2015-02-13 00:38:15 GMT
* expire date: 2016-02-13 00:38:15 GMT
* subjectAltName: outlook.office365.com matched
* issuer: C=US; ST=Washington; L=Redmond; O=Microsoft Corporation; OU=Microsoft IT; CN=Microsoft IT SSL SHA1
* SSL certificate verify ok.
* Server auth using Basic with user 'login#email.outlook'
> GET /api/1.0/Me/folders/Inbox/messages HTTP/1.1
> Authorization: Basic Ybase64stringU=
> User-Agent: curl/7.21.3 (x86_64-pc-linux-gnu) libcurl/7.21.3 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18
> Host: outlook.office365.com
> Accept: */*
> Content-Type:application/json
>
< HTTP/1.1 404 Not Found
< Content-Length: 0
< Server: Microsoft-IIS/8.0
< request-id: d7967869-c282-4a28-9da2-6b80edd7d965
< Set-Cookie: ClientId=XXQW0EIP0KK9NUIRICS8BQ; expires=Fri, 28-Oct-2016 13:04:08 GMT; path=/; secure; HttpOnly
< X-CalculatedBETarget: AM2PR09MB0452.eurprd09.prod.outlook.com
< X-BackEndHttpStatus: 404
< X-DiagInfo: AM2PR09MB0452
< X-BEServer: AM2PR09MB0452
< X-Powered-By: ASP.NET
< X-FEServer: HE1PR01CA0033
< Date: Thu, 29 Oct 2015 13:04:08 GMT
<
* Connection #0 to host outlook.office365.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
any ideas?
If you had exceeded a quota, I would expect you would receive a 429 status code. Microsoft don't usually publish an exact threshold for their services as they reserve the right to adjust them...
so users can consume the maximum number of resources without degrading the reliability and performance
(The above quote is specifically in respect of Sharepoint, but given the lack of published limits for pretty much all REST APIs I imagine the principle holds).
The 404 would usually indicate something isn't quite right... if your user account was reasonably new it could indicate it hadn't propagated to all servers yet (although in your case that doesn't seem to be the issue as you must have had the account for >24 hours).
From a URL point of view... the v1 URL is outlook.office.com/api/v1.0/me/messages and the new beat URL is outlook.office.com/api/v1.0/me/messages these addresses seem to work for me... but I get a 404 if I use the address you are using... so double-check the URL.
I'm running CouchDB 1.6.1 on Windows 64bit server 2012 R2, usually we use nginx to manage the SSL however this time I've attempted using CouchDB directly.
Our SSL is a GlobalSign organizational SSL and I have the cert, private key and intermediate cert from the provider. I have setup my local.ini as follow:
[daemons]
; enable SSL support by uncommenting the following line and supply the PEM's below.
; the default ssl port CouchDB listens on is 6984
httpsd = {couch_httpd, start_link, [https]}
[ssl]
cert_file = ../ssl/organizational.crt
key_file = ../ssl/privatekeyfile.key
; set to true to validate peer certificates
;verify_ssl_certificates = false
; Path to file containing PEM encoded CA certificates (trusted
; certificates used for verifying a peer certificate). May be omitted if
; you do not want to verify the peer.
cacert_file = ../ssl/intermediate.crt
When I check via curl I get the following output:
curl -k -v https://companyURL.com:6984
* Rebuilt URL to: https://companyURL.com:6984/
* Hostname was NOT found in DNS cache
* Trying IP.IP.IP.IP...
* Connected to companyURL.com (IP.IP.IP.IP) port 6984 (#0)
* 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-SHA384
* Server certificate:
* subject: C=GB; ST=LONDON; L=LONDON; OU=IT; O=COMPANY;CN=*.edge10hosted.org
* start date: 2015-03-27 14:18:04 GMT
* expire date: 2018-05-03 11:17:17 GMT
* issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign Organization Validation CA - SHA256 - G2
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET / HTTP/1.1
> User-Agent: curl/7.39.0
> Host: companyURL.com:6984
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: CouchDB/1.6.1 (Erlang OTP/R16B02)
< Date: Tue, 31 Mar 2015 13:00:39 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 151
< Cache-Control: must-revalidate
<
{"couchdb":"Welcome","uuid":"34155abcacbffc53e67a224f5f1ea7c7","version":"1.6.1","vendor":{"version":"1.6.1","name":"The Apache Software Foundation"}}
* Connection #0 to host companyURL.com left intact
And running https://www.sslshopper.com/ssl-checker.html checks out fine.
CouchDB logs show
SSL: certify: tls_connection.erl:2286:Fatal error: decode error
Any thoughts as to what the issue could be as the certificates work fine elsewhere and via nginx.