I can't seem to connect to a specific server over SSL from our Ubuntu servers. Locally, on my Mac, it works flawlessly.

The server address: powerschool.spokaneschools.org

curl -v https://powerschool.spokaneschools.org output:

  • Rebuilt URL to: https://powerschool.spokaneschools.org/
  • Hostname was NOT found in DNS cache
  • Trying
  • Connected to powerschool.spokaneschools.org ( port 443 (#0)
  • successfully set certificate verify locations:
  • CAfile: none CApath: /etc/ssl/certs
  • SSLv3, TLS handshake, Client hello (1):
  • Unknown SSL protocol error in connection to powerschool.spokaneschools.org:443
  • Closing connection 0 curl: (35) Unknown SSL protocol error in connection to powerschool.spokaneschools.org:443

openssl s_client -connect powerschool.spokaneschools.org:443 output:

no peer certificate available
No client certificate CA names sent
SSL handshake has read 0 bytes and written 0 bytes
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
    Protocol  : SSLv3
    Cipher    : 0000
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1466726411
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)

I tried checking the site in different SSL check tools, all seem to be OK (apart from some security issues). I have no issues connecting to other servers, even within that domain.


$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.4 LTS
Release:        14.04
Codename:       trusty

$ curl -V
curl 7.35.0 (x86_64-pc-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smtp smtps telnet tftp 
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP 

$ openssl version -a
OpenSSL 1.0.1f 6 Jan 2014
built on: Mon May  2 16:53:18 UTC 2016
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) 
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"
  • 1
    Works fine for me. Either try using the "-k" option on curl, or please provide distro version and curl version ("curl -V") so we can understand the issue better. – jehad Jun 24 '16 at 1:29
  • 2
    @jehad added more info, adding -k had no effect. Did you manage to run it on ubuntu? – Kuf Jun 24 '16 at 3:29
  • 1
    I'm using the exact same version of software as you (ubuntu server 14.04.4, running curl 7.35.0, openssl 1.0.1f), and I've also tried on my personal desktop machine running LinuxMint 17.3 (which also has the same curl/openssl components). My ubuntu server is running in a virtualbox VM. So, I guess it could come down to your infrastructure... what runs your servers, is it a cloud host, local machines? And, is there a firewall or proxy? And as a scientific test, have you tried a reference test (e.g. "superuser.com:443" or "google.com:443")? – jehad Jun 24 '16 at 7:32
  • @jehad no proxy, firewall has correct exceptions (AWS VPC), and SSL connection to all other servers works, even other servers in that domain – Kuf Jun 24 '16 at 13:58
  • It's hard to say what to do next, since everything points to a problem in your specific environment; if all public servers are reachable, but not this one, it really sounds like there must be a typo in your AWS security group. Do you know how to tcpdump and wireshark? Reading Steffen Ullrich's responses below, he is correct in his analysis, and a tcpdump may help confirm. Other basic experiments... 1) try another VM/VPC (on your local laptop or in AWS), 2) May sound stupid, but forget curl, have you tried a basic ping ("ping powerschool.spokaneschools.org")? – jehad Jun 24 '16 at 19:45

This works for me and it should work with your curl/openssl version too. errno 104 means a connection reset so I assume that some middlebox like a firewall is causing the problem. Check from another network where you can be sure that there are no firewalls involved.

  • I don't think this is a firewall issue - I can connect to the same server without SSL and I can connect to other servers in that domain, but not to that specific one. if it was a firewall issue I would expect all calls to that domain to fail. – Kuf Jun 24 '16 at 13:57
  • 1
    @Kuf: this depends on the firewall. If it is a deep inspection firewall it will look at the connection target inside the TLS ClientHello message and block it if it does not like it. Since it works for me with the same version of openssl on same OS and the same target IP address and since the underlying TCP connection works but the server (or firewall) resets the connection it must be an issue in your network - or the server blocking you. – Steffen Ullrich Jun 24 '16 at 14:00
  • The server are in amazon VPC, and the only 'firewall' we use is the security groups, which allow all transport over port 443 – Kuf Jun 24 '16 at 14:04
  • @Kuf: "SSL handshake has read 0 bytes and written 0 bytes" - looks like the reset happened before ClientHello was sent, so it is a block at the TCP level - either at your firewall or at some other firewall in front of the server. – Steffen Ullrich Jun 24 '16 at 14:43
  • Since it's working for you but not for me, is it safe to assume that the issue in on my server? – Kuf Jun 24 '16 at 16:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.