HAproxy gives no OCSP response back: Response not sent - ssl

I just can't manage to get an OCSP response. Here are the steps I did:
Haproxy cert directory:
Added CA file containing root and intermediate CA certificates with .issuer extension.
Added my .pem cert file including private key, crt etc
Generated OCSP response in DER format with openssl:
openssl ocsp -issuer my_cert.issuer -VAfile my_cert.issuer -cert my_cert.pem -url http://status.thawte.com -header Host status.thawte.com -no_nonce -respout my_cert.ocsp
Response verify OK
my_cert.pem: good
This Update: Mar 14 17:45:00 2022 GMT
Next Update: Mar 21 17:00:00 2022 GMT
3 files are now in my HAproxy cert directory:
my_cert.issuer
my_cert.ocsp
my_cert.pem
This is how my HAproxy config looks like:
global
maxconn 4096
ssl-default-bind-ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA:AES128-GCM-SHA256:RSA+AES128:RC4:HIGH:!MD5:!aNULL:!EDH:!CAMELLIA
log 127.0.0.1 local0 debug
defaults
log global
mode http
option httplog
option dontlognull
option forwardfor
option http-server-close
stats enable
stats uri /stats
timeout connect 3000ms
timeout client 25000ms
timeout server 25000ms
frontend ssl_check
bind :::80
bind :::443 ssl crt /usr/local/etc/haproxy/certs/my_cert.pem
acl https ssl_fc
http-request set-header X-Forwarded-Proto http if !https
http-request set-header X-Forwarded-Proto https if https
mode http
use_backend %[base,lower,map_beg(/usr/local/etc/haproxy/ssl.map)] if { base,lower,map_beg(/usr/local/etc/haproxy/ssl.map) -m found }
default_backend ssl_check
backend ssl_check
mode http
errorfile 503 /usr/local/etc/haproxy/errors/certificate_response.http
This is how my fake backend looks like using a manipulated 503 errorfile giving response 200 back:
HTTP/1.0 200 Found
Cache-Control: no-cache
Connection: close
Content-Type: text/plain
200 Found
Reloaded HAproxy afterwards but I get still the same output:
$ echo quit | openssl s_client -connect 127.0.0.1:443 -tlsextdebug -status
CONNECTED(00000003)
TLS server extension "renegotiation info" (id=65281), len=1
0001 - <SPACES/NULS>
TLS server extension "EC point formats" (id=11), len=4
0000 - 03 00 01 02 ....
TLS server extension "session ticket" (id=35), len=0
OCSP response: no response sent
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte RSA CA 2018
verify return:1
[...]
---
Certificate chain
0 s:/[...]
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
subject=/[...]
issuer=/
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4377 bytes and written 441 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: FDAA738CD5049E2D14F5F7AD1C2CBCA36B938B94755F697E4CE0DCD40342791E
Session-ID-ctx:
Master-Key: [...]
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
[...]
Start Time: 1647360170
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
DONE
C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
This is how the HAproxy package is setup regarding to OpenSSL etc:
# haproxy -vv
HA-Proxy version 1.8.19 2019/02/11
Copyright 2000-2019 Willy Tarreau <willy#haproxy.org>
Build options :
TARGET = linux2628
CPU = generic
CC = gcc
CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -Wno-null-dereference -Wno-unused-label
OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1
Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Built with OpenSSL version : OpenSSL 1.1.0j 20 Nov 2018
Running on OpenSSL version : OpenSSL 1.1.0j 20 Nov 2018
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
Built with Lua version : Lua 5.3.3
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND
Encrypted password support via crypt(3): yes
Built with multi-threading support.
Built with PCRE version : 8.39 2016-06-14
Running on PCRE version : 8.39 2016-06-14
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity("identity"), deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with network namespace support.
Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.
Available filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace
Tested it on a docker-compose setup and on a live machine also but in both cased I get ther certificate chain back etc but the OCSP response field is still empty:
OCSP response: no response sent
What am i doing wrong?!

Was able to sort it out. The naming convention of the certificate file name must be followed and was wrong.
Wrong:
my_cert.issuer
my_cert.ocsp
my_cert.pem
Correct:
my_cert.pem.issuer
my_cert.pem.ocsp
my_cert.pem
Then I was able to get an OCSP response from my HAproxy test instance back.

Related

How can I detect if my service is using SSL or TLS and which version

There are options to specify TLS or SSL on weblogic server & webservers communicating [LISTENING] over HTTPS.
I do not have access to web or app server configurations, however i wish to determine if my connection to webserver [nginx, apache http webserver] or appserver [weblogic] over HTTPS is using SSL or TLS and which version of it.
If & how is it possible to determine ? Kindly suggest.
If you are not able to use some online tools for your service or your service is not hosted to public internet, then there are somethings that you can try.
You can use nmap as nmap -sV --script ssl-enum-ciphers -p <port> <host> to see what TLS versions and particularly what ciphers on which your server is responding.
If you don't have nmap or you are not allowed to install nmap on the system from your the service is reachable, then you can use some default tools to see what ciphers are available.
eg:
openssl: You can use openssl to connect to the server and you can specify the ssl ciphers in the command line.
eg:
$ openssl s_client -connect <host>:<port> -tls1_2 -cipher AES128-GCM-SHA256
If you see a successful connection, then you can be sure that the server is able to negotiate using that TLS version, TLSv1.2 in the example, and using that cipher, TLS_RSA_WITH_AES_128_GCM_SHA256 in the example.
You can find all the ciphers that are valid for openssl here. A sample run would look like this:
$ openssl s_client -connect example.com:443 -tls1_2 -cipher AES128-GCM-SHA256
CONNECTED(00000005)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA
verify return:1
depth=0 C = US, ST = California, L = Los Angeles, O = Internet Corporation for Assigned Names and Numbers, OU = Technology, CN = www.example.org
verify return:1
---
Certificate chain
....
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHQDCCBiigAwIBAgIQD9B43Ujxor1NDyupa2A4/jANBgkqhkiG9w0BAQsFADBN
...
0Gs4+eH6F9h3SojmPTYkT+8KuZ9w84Mn+M8qBXUQoYoKgIjN
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Los Angeles/O=Internet Corporation for Assigned Names and Numbers/OU=Technology/CN=www.example.org
issuer=/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 4297 bytes and written 408 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
...
TLS session ticket:
0000 - 57 04 cc 0f 69 dc 93 6c-e5 d6 50 0a 1c d0 d8 ce W...i..l..P.....
...
0090 - 9a 34 af 1e c2 09 cf 00-6d 68 36 41 09 40 de 0a .4......mh6A.#..
Start Time: 1558594372
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
curl: you can use curl to do the same thing. eg:
$ curl https://example.com --tlsv1.2 --ciphers AES128-GCM-SHA256 -w "%{http_code}\n" -o /dev/null -s
In this case, you will get the output as a valid response code, say 200 if the connection is successful and 000 is the Handshake failed, so you can differentiate using that.
Note: the TLS version supported in openssl and curl can be looked up by checking the --help in both cases. eg:
curl:
-1, --tlsv1 Use >= TLSv1 (SSL)
--tlsv1.0 Use TLSv1.0 (SSL)
--tlsv1.1 Use TLSv1.1 (SSL)
--tlsv1.2 Use TLSv1.2 (SSL)
--tlsv1.3 Use TLSv1.3 (SSL)
openssl:
-tls1_2 - just use TLSv1.2
-tls1_1 - just use TLSv1.1
-tls1 - just use TLSv1
-dtls1 - just use DTLSv1

Scrapy unable to connect to HTTPS site that only supports older TLSv1. Connection Lost

Using scrapy 1.6.0 (twisted 18.9.0, pyopenssl 19.0.0, openssl 1.0.2r, osx 10.14.3). I've ruled out user agent and robots.txt. Seems to be a certificate negotiation issue. There is no web proxy involved.
Destination is https://www.labor.ny.gov/
To reproduce:
04:49:59 dork#Dorks-MacBook:~
0 $ scrapy shell
.
.
.
>>> fetch('https://www.labor.ny.gov')
2019-04-05 16:45:11 [scrapy.core.engine] INFO: Spider opened
Traceback (most recent call last):
File "<console>", line 1, in <module>
File "/Users/dork/project/venv/lib/python3.6/site-packages/scrapy/shell.py", line 115, in fetch
reactor, self._schedule, request, spider)
File "/Users/dork/project/venv/lib/python3.6/site-packages/twisted/internet/threads.py", line 122, in blockingCallFromThread
result.raiseException()
File "/Users/dork/project/venv/lib/python3.6/site-packages/twisted/python/failure.py", line 467, in raiseException
raise self.value.with_traceback(self.tb)
twisted.web._newclient.ResponseNeverReceived: [<twisted.python.failure.Failure twisted.internet.error.ConnectionLost: Connection to the other side was lost in a non-clean fashion: Connection lost.>]
Trying to connect and negotiating via OpenSSL directly on the command line seems to fail as well:
0 $ openssl version
OpenSSL 1.0.2r 26 Feb 2019
04:49:59 dork#Dorks-MacBook:~
0 $ openssl s_client -connect www.labor.ny.gov:443
CONNECTED(00000003)
4472571500:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 307 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1554497411
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
However if I force openssl to TLSv1 it seems to work. I just don't know how to force that from scrapy -> twisted -> pyopenssl -> OpenSSL or if it's possible.
04:49:59 dork#Dorks-MacBook:~
0 $ openssl s_client -tls1 -connect www.labor.ny.gov:443
CONNECTED(00000003)
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization Validation CA - SHA256 - G2
verify return:1
depth=0 C = US, ST = New York, L = Albany, O = New York State Office for Technology, CN = labor.ny.gov
verify return:1
---
Certificate chain
0 s:/C=US/ST=New York/L=Albany/O=New York State Office for Technology/CN=labor.ny.gov
i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
.
.
.
Postman can't fetch the page either. It seems like anything relying on OpenSSL sort of silently dies.
Not a full answer; CW in case anyone can add the scrapy (or related) part.
Man that server is bad!
It supports only SSL2 SSL3 and TLS1.0 where the first two are completely broken and the first was completely broken last century. It identifies as IIS/6.0 which dates to Windows Server 2003 -- which was end-of-life long ago.
FWLIW it's not actually version-intolerant, or broken for hello over 256 bytes, as some defective implementations were discovered to be years ago; if I use OpenSSL 1.0.2 to send it ClientHello offering TLS1.2 with ciphers restricted to kRSA, it does negotiate down to TLS1.0 correctly. It only fails for the OpenSSL>=1.0.2 default ClientHello, which uses a significantly larger cipherlist than previous versions because TLS1.2 added a whole bunch of new ciphersuites for the new AEAD format and new PRF scheme. Forcing TLS1.0 has the same effect, because it causes OpenSSL to offer only the smaller list of ciphersuites which were valid in TLS1.0. I vaguely recall an XP-era bug triggered by 'large' cipherlists, and that might be the problem here.
It's not the certificate. The certificate is the only thing they have right.

my website not responding with SSL

I have a website hosted on a VPS running CentOS 6 and running fine. Now I have to make it accesible with SSL, so I configured /etc/httpd/conf/httpd.confand /etc/httpd/conf.d/ssl.conf to make httpd listen to port 443, then binding the virtualhost related to the website to the same port.
The apparent result of the whole configuration may be resumed by the following diagnostics that also resumes some tests I performed (I masked data where necessary, and my.site.com is dummy):
# service httpd restart
Stopping httpd: [ OK ]
Starting httpd: [ OK ]
# httpd -S
VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
*:443 my.site.com (/etc/httpd/conf.d/ssl.conf:74)
*:80 my.site.com (/etc/httpd/conf/httpd.conf:1022)
*:8888 my.site.com (/etc/httpd/conf/httpd.conf:1045)
Syntax OK
# openssl s_client -connect localhost:443
CONNECTED(00000003)
depth=2 O = [Some authority here], CN = [Some authority here] Root CA X3
verify return:1
depth=1 C = US, O = [Some authority here], CN = [Some authority here] X3
verify return:1
depth=0 CN = my.site.com
verify return:1
---
Certificate chain
0 s:/CN=my.site.com
i:/C=US/O=[some authority here]/CN=[some authority here] X3
1 s:/C=US/O=[some authority here]/CN=[some authority here] X3
i:/O=[some authority here]/CN=[Some authority here] Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
[some certificate codes here]
-----END CERTIFICATE-----
subject=/CN=my.site.com
issuer=/C=US/O=[some authority here]/CN=[some authority here] X3
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 3672 bytes and written 373 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: [some coding here]
Session-ID-ctx:
Master-Key:
[some coding here]
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
[other codes here]
Start Time: 1483709215
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
closed
# openssl s_client -connect [my.site.com's IP] -state -nbio 2>&1 | grep "^SSL"
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:error in SSLv2/v3 read server hello A
SSL_connect:SSLv3 read server hello A
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read server session ticket A
SSL_connect:SSLv3 read finished A
SSL handshake has read 3672 bytes and written 373 bytes
SSL-Session:
SSL3 alert read:warning:close notify
SSL3 alert write:warning:close notify
# iptables -L -v | grep https
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:https
# netstat -lnp | grep 443
tcp 0 0 :::443 :::* LISTEN 22682/httpd
Now, the website is still responding via the usual browser http://my.site.com address, while it return ERR_CONNECTION_TIMED_OUT if trying https://my.site.com.
Furthermore, accessing by remote I obtain:
# openssl s_client -connect [my.site.com's IP:443]
connect: No route to host
connect:errno=113
So, what is the problem or how can I investigate its origin?
Thanks in advance for your help.

Centos 6 TLS with Lets Encrypt CA cert - why does OpenSSL verify return code 19 (self signed cert in chain)?

Do you know why using a Let's Encrypt cert for TLS would result in a client failing at the SSL handshake point with error 19 (self signed cert in chain)? I am developing an app in C that uses the Mosquitto libraries to open the connection (and fails at the handshake) but to simplify this question I'm going to demonstrate the problem using the mosquitto_sub command (which we know works).
I am using Centos 6.2 with Let's Encrypt certificates for my website without any issues (because they're free, automated, and open). I now want to use the same certificate issued by Let's Encrypt to secure a TLS connection between my server and any remote client. TLS is being used for connections to the Mosquitto MQTT broker in fact, on port 8881. The mosquitto.conf file on my server contains:
...
user mosquitto
listener 8883 example.com
cafile /etc/mosquitto/certs/chain-ca.pem # These 3 from Let's Encrypt
certfile /etc/mosquitto/certs/cert.pem
keyfile /etc/mosquitto/certs/privkey.pem
require_certificate false
...
I have several network interfaces on my CentOS server and my domain, "example.com" resolves with the dig command to the IP of interface eth0:1:
[root#spiff mosquitto]# dig example.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.2 <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 804
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 300 IN A 158.234.234.24
;; AUTHORITY SECTION:
example.com. 300 IN NS dns0.ns.co.uk.
example.com. 300 IN NS dns1.ns.co.uk.
;; Query time: 41 msec
;; SERVER: 151.236.220.5#535(11.226.220.5)
;; WHEN: Sun Oct 30 19:21:07 2016
;; MSG SIZE rcvd: 101
I believe this is significant because the certificate for 'example.com' that I've created with Let's Encrypt has a CN which has to resolve with DNS to the IP address of the NIC that the Mosquitto listener is bound to, otherwise from the perspective of OpenSSL I'm serving the wrong certificate to any clients.
The server doesn't have any issues on startup.
After a lot of Googling, I understand (maybe wrongly) that the client needs to be handed as a parameter the certificate of the CA (certification authority) that signed the cert for 'example.com' when it makes a connection to the server, because it will check that the CA used to sign example.com's certificate is trusted, and so we use the --cafile [certificate-authority-cert.crt] parameter to pass this. I appreciate that this is specific to TLS connections and that web clients don't use this feature.
When a client on the same Centos 6.2 server (which could be my program but to simplify things is the out-of-the-box mosquitto_sub command) connects with these parameters I see this error:
mosquitto_sub -h example.com -p 8883 -t test -u mr-user -P P#55W0rD --cafile /etc/pki/tls/certs/lets-encrypt-x3-cross-signed.pem -d
Error: A TLS error occurred
Because the Mosquitto broker is not very specific about the value of errno on a failure, I try again using the s_client feature of openSSL instead:
[root#spiff certs]# openssl s_client -connect example.com:8883 -CAfile lets-encrypt-x3-cross-signed.pem
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/CN=www.example.com
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
2 s:/O=Digital Signature Trust Co./CN=DST Root CA X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFDjCCA/agAwIBAgISA12o6mO9oS364BF5UVgSAD7TMA0GCSqGSIb3DQEBCwUA
[... lines removed for brevity ...]
A+q6hf00nJJsEvGmhVzQG5zAn6ojcWgT3EhurPien7Y16+kIS5tdz9xbeCgLTOrJ
BXA=
-----END CERTIFICATE-----
subject=/CN=www.example.com
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 3999 bytes and written 373 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: E8D32590BAB26FF5811D39D775B3F455CAC3E8747866FA251DDA2032FA88E349
Session-ID-ctx:
Master-Key: 1B45DF54D11BC44D96AEAC940291B4D3BBAE56D6431E746873DC4F15DC1219F02019F4D903CAA6E8B23AF83CE291F4A6
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - d9 fb 28 9f c9 7c ba b3-26 ff dd 75 53 d1 12 65 ..(..|..&..uS..e
0010 - 91 76 91 2b f8 a2 b4 4b-0a e2 97 eb ce 8e a1 af .v.+...K........
[ ... lines ommitted for brevity ... ]
00a0 - 71 c3 a9 f3 16 c4 04 17-d1 e8 b0 75 e8 80 e9 fb q..........u....
Start Time: 1477857075
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
Why does Verify think that I'm using a self-signed certificate? Is there something else that I need to do, for instance does OpenSSL check the certificate store in /etc/pki/tls for a certificate for the root authority that signed Let's Encrypt's certificate and not find it perhaps when you link in the OpenSSL libs? Is it possible that the trust store under /etc/pki doesn't know about the root authority used by Let's Encrypt already? I got lets-encrypt-x3-cross-signed.pem after reading instructions on the Let's Encrypt Chain Of Trust page, is this the wrong file completely?

OpenSSL Command to check if a server is presenting a certificate

I'm trying to run an openssl command to narrow down what the SSL issue might be when trying to send an outbound message from our system.
I found this command in another topic: Using openssl to get the certificate from a server
openssl s_client -connect ip:port -prexit
The output of this results in
CONNECTED(00000003)
15841:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 121 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
Does this mean the server isn't presenting any certificate? I tried other systems on a different ip:port and they present a certificate successfully.
Does mutual authentication affect this command with -prexit?
--Update--
I ran the command again
openssl s_client -connect ip:port -prexit
And I get this response now
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 121 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
I added -ssl3 to the command
openssl s_client -connect ip:port -prexit -ssl3
Response:
CONNECTED(00000003)
write:errno=104
---
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
SSL-Session:
Protocol : SSLv3
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
Start Time: 1403907236
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
Also trying -tls1
CONNECTED(00000003)
write:errno=104
---
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
SSL-Session:
Protocol : TLSv1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
Start Time: 1403907267
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
I was debugging an SSL issue today which resulted in the same write:errno=104 error. Eventually I found out that the reason for this behaviour was that the server required SNI (servername TLS extensions) to work correctly. Supplying the -servername option to openssl made it connect successfully:
openssl s_client -connect domain.tld:443 -servername domain.tld
15841:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
...
SSL handshake has read 0 bytes and written 121 bytes
This is a handshake failure. The other side closes the connection without sending any data ("read 0 bytes"). It might be, that the other side does not speak SSL at all. But I've seen similar errors on broken SSL implementation, which do not understand newer SSL version. Try if you get a SSL connection by adding -ssl3 to the command line of s_client.
I encountered the write:errno=104 attempting to test connecting to an SSL-enabled RabbitMQ broker port with openssl s_client.
The issue turned out to be simply that the user RabbitMQ was running as did not have read permissions on the certificate file. There was little-to-no useful logging in RabbitMQ.
In my case the ssl certificate was not configured for all sites (only for the www version which the non-www version redirected to). I am using Laravel forge and the Nginx Boilerplate config
I had the following config for my nginx site:
/etc/nginx/sites-available/timtimer.at
server {
listen [::]:80;
listen 80;
server_name timtimer.at www.timtimer.at;
include h5bp/directive-only/ssl.conf;
# and redirect to the https host (declared below)
# avoiding http://www -> https://www -> https:// chain.
return 301 https://www.timtimer.at$request_uri;
}
server {
listen [::]:443 ssl spdy;
listen 443 ssl spdy;
# listen on the wrong host
server_name timtimer.at;
### ERROR IS HERE ###
# You eighter have to include the .crt and .key here also (like below)
# or include it in the below included ssl.conf like suggested by H5BP
include h5bp/directive-only/ssl.conf;
# and redirect to the www host (declared below)
return 301 https://www.timtimer.at$request_uri;
}
server {
listen [::]:443 ssl spdy;
listen 443 ssl spdy;
server_name www.timtimer.at;
include h5bp/directive-only/ssl.conf;
# Path for static files
root /home/forge/default/public;
# FORGE SSL (DO NOT REMOVE!)
ssl_certificate /etc/nginx/ssl/default/2658/server.crt;
ssl_certificate_key /etc/nginx/ssl/default/2658/server.key;
# ...
# Include the basic h5bp config set
include h5bp/basic.conf;
}
So after moving (cutting & pasting) the following part to the /etc/nginx/h5bp/directive-only/ssl.conf file everything worked as expected:
# FORGE SSL (DO NOT REMOVE!)
ssl_certificate /etc/nginx/ssl/default/2658/server.crt;
ssl_certificate_key /etc/nginx/ssl/default/2658/server.key;
So it is not enough to have the keys specified only for the www version even, if you only call the www version directly!
I was getting the below as well trying to get out to github.com as our proxy re-writes the HTTPS connection with their self-signed cert:
no peer certificate available
No client certificate CA names sent
In my output there was also:
Protocol : TLSv1.3
I added -tls1_2 and it worked fine and now I can see which CA it is using on the outgoing request. e.g.:
openssl s_client -connect github.com:443 -tls1_2
I had a similar issue. The root cause was that the sending IP was not in the range of white-listed IPs on the receiving server. So, all requests for communication were killed by the receiving site.
I have met the same problem . but use IP fine;
I specify ip host in /etc/hosts
use IP work fine, but host can't