EIdOSSLUnderlyingCryptoError Exception - delphi

I am using Indy (IdHTTP, OpenSSL). I use this simple code to download a page
var
IdHTTP: TIdHTTP;
begin
IdHTTP:=TIdHTTP.Create;
try
IdHTTP.Get('https://ezfile.ch/?m=help&a=tos');
finally
IdHTTP.Free;
end;
end;
It returns:
EIdOSSLUnderlyingCryptoError exception "Error connecting with SSL.
error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert internal error"
The site uses TLS 1.1, AES_128_CBC_SHA1, ECDHE-ECDSA.
It should be easily reproducible.
Tried with various Delphi versions, Indy 10.6.2, various OpenSSL version. Changing SSLVersion option did not help.
What could be the problem?

Here is sample code on how to fix this issue using SSL_set_tlsext_host_name
It is done by creating a custom class inheriting from TIdHTTP, and calling SSL_set_tlsext_host_name with the correct parameters by using the OnStatusInfoEx event of TIdSSLIOHandlerSocketOpenSSL
This issue started appearing on all Cloudflare SSL-enabled websites about a month ago.
program Project1;
{$APPTYPE CONSOLE}
uses
System.Classes, IdHTTP, IdSSL, IdSSLOpenSSL, IdSSLOpenSSLHeaders, IdCTypes;
type
TCustomIdHTTP = class(TIdHTTP)
public
constructor Create(AOwner: TComponent);
private
procedure OnStatusInfoEx(ASender: TObject; const AsslSocket: PSSL; const AWhere, Aret: TIdC_INT; const AType, AMsg: String);
end;
{ TCustomIdHTTP }
constructor TCustomIdHTTP.Create(AOwner: TComponent);
begin
IOHandler := TIdSSLIOHandlerSocketOpenSSL.Create(nil);
with IOHandler as TIdSSLIOHandlerSocketOpenSSL do begin
OnStatusInfoEx := Self.OnStatusInfoEx;
SSLOptions.Method := sslvSSLv23;
SSLOptions.SSLVersions := [sslvTLSv1_2, sslvTLSv1_1, sslvTLSv1];
end;
inherited Create(AOwner);
end;
procedure TCustomIdHTTP.OnStatusInfoEx(ASender: TObject; const AsslSocket: PSSL; const AWhere, Aret: TIdC_INT;
const AType, AMsg: String);
begin
SSL_set_tlsext_host_name(AsslSocket, Request.Host);
end;
//////////////////
var
MyHTTP: TCustomIdHTTP;
begin
MyHTTP := TCustomIdHTTP.Create(nil);
// Your normal Indy HTTP code here
MyHTTP.Free;
end.

What could be the problem?
The site appears operational to me. I could even connect with TLS 1.2.
I failed when trying to connect with SSLv3, however. That's a good thing.
Its may be a bug in the library. That is, its trying to connect with SSLv3, or its doing something else wrong, like omitting the server name with SNI. Or, you are loading the wrong version of OpenSSL at runtime. That is, you compiled against OpenSSL 1.0.2, but you are loading a system down level version, like 0.9.8, at run time.
You can clear the verify error:num=20 below by fetching the CA and then passing it to s_client via -CAfile.
$ echo -e "GET /?m=help&a=tos HTTP/1.1\r\nHost: ezfile.ch\r\n\r\n" | \
openssl s_client -connect ezfile.ch:443 -tls1_1 -servername ezfile.ch -ign_eof
CONNECTED(00000003)
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO ECC Certification Authority
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL Multi-Domain/CN=sni42046.cloudflaressl.com
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Domain Validation Secure Server CA 2
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Domain Validation Secure Server CA 2
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Certification Authority
2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Certification Authority
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGtjCCBlugAwIBAgIRAPpZe3LxW3syzgKsuUmSJqEwCgYIKoZIzj0EAwIwgZIx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV
BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTgwNgYDVQQD
Ey9DT01PRE8gRUNDIERvbWFpbiBWYWxpZGF0aW9uIFNlY3VyZSBTZXJ2ZXIgQ0Eg
MjAeFw0xNTAzMjUwMDAwMDBaFw0xNTA5MzAyMzU5NTlaMGsxITAfBgNVBAsTGERv
bWFpbiBDb250cm9sIFZhbGlkYXRlZDEhMB8GA1UECxMYUG9zaXRpdmVTU0wgTXVs
dGktRG9tYWluMSMwIQYDVQQDExpzbmk0MjA0Ni5jbG91ZGZsYXJlc3NsLmNvbTBZ
MBMGByqGSM49AgEGCCqGSM49AwEHA0IABGtNNuTz7vtNt80pyh8FgGuPH78FQb1D
FsR0tBKe+ygNLGysmcTkhekQeupBYMFsfHdjUy51iabkf1a2m75iqM6jggS2MIIE
sjAfBgNVHSMEGDAWgBRACWFn8LyDcU/eEggsb9TUK3Y9ljAdBgNVHQ4EFgQUo9+D
XFOnVv7lgCtpOyO+2vbluvswDgYDVR0PAQH/BAQDAgeAMAwGA1UdEwEB/wQCMAAw
HQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCME8GA1UdIARIMEYwOgYLKwYB
BAGyMQECAgcwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLmNv
bS9DUFMwCAYGZ4EMAQIBMFYGA1UdHwRPME0wS6BJoEeGRWh0dHA6Ly9jcmwuY29t
b2RvY2E0LmNvbS9DT01PRE9FQ0NEb21haW5WYWxpZGF0aW9uU2VjdXJlU2VydmVy
Q0EyLmNybDCBiAYIKwYBBQUHAQEEfDB6MFEGCCsGAQUFBzAChkVodHRwOi8vY3J0
LmNvbW9kb2NhNC5jb20vQ09NT0RPRUNDRG9tYWluVmFsaWRhdGlvblNlY3VyZVNl
cnZlckNBMi5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLmNvbW9kb2NhNC5j
b20wggL9BgNVHREEggL0MIIC8IIac25pNDIwNDYuY2xvdWRmbGFyZXNzbC5jb22C
ECouYm90aXNrYWNhZmUucnOCFCouZGVlZm9yZGVzaWduLmNvLnVrgg0qLmRvcmVn
YW1hLnR2gg8qLmR1dGNocG9ybi5vcmeCCyouZXpmaWxlLmNoggwqLmZhaGFtdS5u
ZXSCDCouZmFoYW11Lm9yZ4IPKi5ncmVlbmhhYml0LnVzgg8qLmp1ZGlrYXJ0dS5j
b22CFCouanVtcGZyb21yb29mLnRvZGF5ggwqLm1vYml1cy54eXqCDioubXV0aHJv
bmUubmV0ghEqLm15YWxwaGFob3N0LmNvbYIOKi5uZXdzYmVkcy5jb22CDyoucGF1
bGRpYXouYXNpYYINKi5wYXVsZGlhei5tZYIVKi5wb2thenktY2hlbWljem5lLnBs
ghMqLnNpeHR5c2l4c291bmQuY29tggsqLnNvYXdyLm9yZ4ISKi5zdGV2aWVjcmlw
cHMuY29tghoqLnN3aW5nc2V0cHJpY2Vjb21wYXJlLmNvbYILKi50dWJ5bG8ucGyC
DmJvdGlza2FjYWZlLnJzghJkZWVmb3JkZXNpZ24uY28udWuCC2RvcmVnYW1hLnR2
gg1kdXRjaHBvcm4ub3JnggllemZpbGUuY2iCCmZhaGFtdS5uZXSCCmZhaGFtdS5v
cmeCDWdyZWVuaGFiaXQudXOCDWp1ZGlrYXJ0dS5jb22CEmp1bXBmcm9tcm9vZi50
b2RheYIKbW9iaXVzLnh5eoIMbXV0aHJvbmUubmV0gg9teWFscGhhaG9zdC5jb22C
DG5ld3NiZWRzLmNvbYINcGF1bGRpYXouYXNpYYILcGF1bGRpYXoubWWCE3Bva2F6
eS1jaGVtaWN6bmUucGyCEXNpeHR5c2l4c291bmQuY29tgglzb2F3ci5vcmeCEHN0
ZXZpZWNyaXBwcy5jb22CGHN3aW5nc2V0cHJpY2Vjb21wYXJlLmNvbYIJdHVieWxv
LnBsMAoGCCqGSM49BAMCA0kAMEYCIQCdDfGZutuJWSUn3ytumOYCbpeRjkuHN5ZN
7L0AganZGQIhANpKjy+PNLTWCOzGCcva3fEbCLzpCmu2PUatE9xBl+Ck
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/OU=PositiveSSL Multi-Domain/CN=sni42046.cloudflaressl.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Domain Validation Secure Server CA 2
---
No client certificate CA names sent
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4166 bytes and written 408 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES128-SHA
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.1
Cipher : ECDHE-ECDSA-AES128-SHA
Session-ID: ACB2C0516C9F57EE6AA973463849A53B07CAF99A6A78EE6C12AC0CDF99CC9C50
Session-ID-ctx:
Master-Key: 0DCCE2B3E57E034B271296C716CFBDC4039AE4E6697A8EF560FD7423A9090ACEC3F924D331C2B8FD0FAE5631C9D8219A
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 64800 (seconds)
TLS session ticket:
0000 - 03 30 b1 f4 75 9a 14 f7-d5 97 03 b3 4e 4d 5e ab .0..u.......NM^.
0010 - d1 15 d5 09 4a 7e 88 8b-d1 ba ed 9d 20 b5 bb f4 ....J~...... ...
0020 - 33 c0 14 44 b3 d7 1d 78-f5 f0 f5 06 dd 57 cb 58 3..D...x.....W.X
0030 - 51 6d 0a 18 a7 97 1b d6-36 ea bd ab a3 5a bc 1e Qm......6....Z..
0040 - 35 47 31 4b 19 cb c5 94-ac c5 41 f1 65 6a 76 d3 5G1K......A.ejv.
0050 - 9e b2 45 e1 3c 5d dd 4d-49 6f 2f f2 18 1b 88 45 ..E.<].MIo/....E
0060 - 9b 9d 50 1e 66 e2 ec c9-e5 87 a1 5a b7 80 d3 60 ..P.f......Z...`
0070 - 6d fe 3e b6 77 0b c2 ba-f9 f9 12 49 f3 55 72 02 m.>.w......I.Ur.
0080 - b1 da 2b 4c a6 74 50 df-11 12 c9 6b 1d 2f da a8 ..+L.tP....k./..
0090 - 4f bc c5 9e ff f1 ff 5d-9a 28 ad e9 4d 43 09 ed O......].(..MC..
00a0 - bb 7d d6 1d fc 39 75 1e-e2 6e 2f f4 a6 69 7e 6c .}...9u..n/..i~l
00b0 - 97 cd 9c 1a 77 0d 14 c7-61 f8 87 cf 24 52 60 3e ....w...a...$R`>
Start Time: 1430097932
Timeout : 7200 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
HTTP/1.1 200 OK
Server: cloudflare-nginx
Date: Mon, 27 Apr 2015 01:18:45 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: __cfduid=dc202f5845fd4246ec401ee26196a7e831430097524; expires=Tue, 26-Apr-16 01:18:44 GMT; path=/; domain=.ezfile.ch; HttpOnly
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified: Mon, 27 Apr 2015 01:18:45 GMT
Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
X-Frame-Options: sameorigin
Access-Control-Allow-Origin: *
CF-RAY: 1dd6b1fac4350874-IAD
...

This code works with the 5273 revision and OpenSSL 1.0.2 / 1.0.2a:
program HttpsGetExample;
{$APPTYPE CONSOLE}
uses
IdHTTP, IdGlobal, SysUtils, Classes;
var
HTTP: TIdHTTP;
ResponseBody: string;
begin
HTTP := TIdHTTP.Create;
try
try
ResponseBody := HTTP.Get('https://ezfile.ch');
WriteLn(ResponseBody);
WriteLn(HTTP.ResponseText);
except
on E: EIdHTTPProtocolException do
begin
WriteLn(E.Message);
WriteLn(E.ErrorMessage);
end;
on E: Exception do
begin
WriteLn(E.Message);
end;
end;
finally
HTTP.Free;
end;
ReadLn;
ReportMemoryLeaksOnShutdown := True;
end.

The above method SSL_set_tlsext_host_name worked for me except that I had to free IOHandler in an added destructor. Otherwise an exception were raised.

Related

WebRequest.GetResponse() is getting an "underlying connection was closed"

I build the WebRequest object and then call GetResponse() on it. The url is "https://services.odata.org/V2/Northwind/Northwind.svc/$metadata".
And it comes up in a browser fine. What's really weird is these are returning a 200 so it should be good. But no data is coming back.
According to Fiddler there are two requests that go out:
Request #1
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
Version: 3.1 (TLS/1.0)
Random: 5E 5B 1A 26 84 02 5A 4B DF 6B BF 22 DF 2C 03 AD 37 62 DA CE 05 79 7E B4 5C 58 AF BE 8C 26 5D CA
"Time": 4/4/1990 2:38:54 PM
SessionID: empty
Extensions:
server_name services.odata.org
supported_groups x25519 [0x1d], secp256r1 [0x17], secp384r1 [0x18]
ec_point_formats uncompressed [0x0]
SessionTicket empty
extended_master_secret empty
renegotiation_info 00
Ciphers:
[C00A] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[C009] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C014] TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C013] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
[0035] TLS_RSA_WITH_AES_256_CBC_SHA
[002F] TLS_RSA_WITH_AES_128_CBC_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
Compression:
[00] NO_COMPRESSION
Response #1
Request #2
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
Version: 3.1 (TLS/1.0)
Random: 5E 5B 1A 26 0D B0 9F BF 4F D8 FC 5D 27 47 A8 7C CB 83 2C 43 4C 2B C3 8A 0C C0 EB 30 3D 6E AB 51
"Time": 4/4/1990 2:38:54 PM
SessionID: empty
Extensions:
server_name services.odata.org
supported_groups x25519 [0x1d], secp256r1 [0x17], secp384r1 [0x18]
ec_point_formats uncompressed [0x0]
SessionTicket empty
extended_master_secret empty
renegotiation_info 00
Ciphers:
[C00A] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[C009] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C014] TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C013] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
[0035] TLS_RSA_WITH_AES_256_CBC_SHA
[002F] TLS_RSA_WITH_AES_128_CBC_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
Compression:
[00] NO_COMPRESSION
Response #2
It was the TLS level. Just add:
ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;

Why does HAProxy close the connection to the HiveMQ MQTT client at the end of the TLS handshake?

I'm trying to establish a TLS connection to a MQTT broker behind a HAProxy instance. At the end of the handshake (TLS 1.2 application data was sent), the server unexpectedly closes the connection.
I'm using self-signed certificates in form of a Keystore and a Truststore. Keystore and Truststore are tested against the server, for example with MQTTFx and with a MQTT3 Paho client.
As I have to use shared subscriptions, I decided to switch to the HiveMQ MQTT5 async client.
The following code illustrates building the client and connecting to the server.
The variable connectionProperties contains information about the broker and the keystores used.
public class MqttConnector {
Logger logger = LoggerFactory.getLogger(MqttConnector.class);
private ConnectionListener connectionListener;
private Properties connectionProperties;
private Mqtt5AsyncClient client;
public MqttConnector() throws SSLException {
this.connectionListener = new ConnectionListener();
this.connectionProperties = ConnectionProperties.get();
this.client = this.buildMqtt5AsyncClient(this.connectionProperties, this.connectionListener);
}
public MqttConnector(ConnectionListener connectionListener, Properties connectionProperties) throws SSLException {
this.connectionListener = connectionListener;
this.connectionProperties = connectionProperties;
this.client = this.buildMqtt5AsyncClient(this.connectionProperties, this.connectionListener);
}
private Mqtt5AsyncClient buildMqtt5AsyncClient(
Properties connectionProperties,
ConnectionListener connectionListener) throws SSLException {
return MqttClient.builder()
.identifier(connectionProperties.getProperty("clientId"))
.serverHost(connectionProperties.getProperty("host"))
.serverPort(Integer.valueOf(connectionProperties.getProperty("port")))
.addConnectedListener(connectionListener)
.addDisconnectedListener(connectionListener)
.sslConfig()
.keyManagerFactory(KeystoreUtil.keyManagerFromKeystore(
new File(connectionProperties.getProperty("keystore_file")),
connectionProperties.getProperty("keystore_pass"),
connectionProperties.getProperty("keystore_pass")))
.trustManagerFactory(KeystoreUtil.trustManagerFromKeystore(
new File(connectionProperties.getProperty("truststore_file")),
connectionProperties.getProperty("truststore_pass")))
.applySslConfig()
.automaticReconnectWithDefaultConfig()
.useMqttVersion5()
.buildAsync();
}
public void connect() {
this.client.connect().whenComplete((connack, throwable) -> {
if (throwable != null) {
logger.error("connection exception", throwable);
} else {
logger.info(connack.toString());
}
});
}
public void disconnect() {
if (this.client != null && this.client.getState().isConnected()) {
this.client.disconnect();
}
}
This is part of the debug log (debugged with additional -Djavax.net.debug=all to see the SSL output). I removed most of the raw data and the certificate information.
At the end of the handshake the connection is closed by the server.I have no idea why this is happening with tried and tested certificates.
javax.net.ssl|DEBUG|01|main|2019-10-15 15:40:50.356 CEST|X509TrustManagerImpl.java:79|adding as trusted certificates (
"certificate" : {
"version" : "v3",
"serial number" : "02 41 2E 94 57 70 85 FC DF CB 6E F1 24 79 E0 C3 53 2C 41 7A",
"signature algorithm": "SHA256withRSA",
"issuer" : "CN=ca.dev-broker.your-server.de",
"not before" : "2019-07-31 16:05:54.000 CEST",
"not after" : "2029-07-28 16:05:54.000 CEST",
"subject" : "CN=dev-broker.your-server.de",
"subject public key" : "RSA",
"extensions" : [
{
ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:false
PathLen: undefined
]
},
{
ObjectId: 2.5.29.15 Criticality=false
KeyUsage [
DigitalSignature
Non_repudiation
Key_Encipherment
]
},
{
ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
DNSName: dev-broker.your-server.de
DNSName: *.dev-broker.your-server.de
]
}
]}
)
15:44:31.015 [main] DEBUG io.netty.util.internal.logging.InternalLoggerFactory - Using SLF4J as the default logging framework
15:44:32.601 [main] DEBUG io.netty.util.internal.PlatformDependent0 - -Dio.netty.noUnsafe: false
15:44:32.603 [main] DEBUG io.netty.util.internal.PlatformDependent0 - Java version: 11
15:44:32.651 [main] DEBUG io.netty.util.internal.PlatformDependent0 - sun.misc.Unsafe.theUnsafe: available
15:44:32.669 [main] DEBUG io.netty.util.internal.PlatformDependent0 - sun.misc.Unsafe.copyMemory: available
15:44:32.687 [main] DEBUG io.netty.util.internal.PlatformDependent0 - java.nio.Buffer.address: available
15:44:32.708 [main] DEBUG io.netty.util.internal.PlatformDependent0 - direct buffer constructor: unavailable
15:44:33.245 [main] DEBUG io.netty.util.internal.PlatformDependent0 - java.nio.Bits.unaligned: available, true
15:44:33.272 [main] DEBUG io.netty.util.internal.PlatformDependent0 - jdk.internal.misc.Unsafe.allocateUninitializedArray(int): unavailable
5:44:50.873 [epollEventLoopGroup-2-1] DEBUG io.netty.handler.ssl.JdkSslContext - Default protocols (JDK): [TLSv1.2, TLSv1.1, TLSv1]
15:44:50.876 [epollEventLoopGroup-2-1] DEBUG io.netty.handler.ssl.JdkSslContext - Default cipher suites (JDK): [TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384]
javax.net.ssl|ALL|19|epollEventLoopGroup-2-1|2019-10-15 15:44:50.877 CEST|SSLContextImpl.java:115|trigger seeding of SecureRandom
javax.net.ssl|ALL|19|epollEventLoopGroup-2-1|2019-10-15 15:44:50.877 CEST|SSLContextImpl.java:119|done seeding of SecureRandom
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:50.962 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS11
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:50.963 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS11
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:50.964 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS11
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:50.964 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS10
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:50.967 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS10
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:50.968 CEST|HandshakeContext.java:290|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS10
javax.net.ssl|WARNING|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.002 CEST|ServerNameExtension.java:255|Unable to indicate server name
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.003 CEST|SSLExtensions.java:256|Ignore, context unavailable extension: server_name
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.009 CEST|SupportedGroupsExtension.java:841|Ignore inactive or disabled named group: ffdhe2048
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.012 CEST|SupportedGroupsExtension.java:841|Ignore inactive or disabled named group: ffdhe3072
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.013 CEST|SupportedGroupsExtension.java:841|Ignore inactive or disabled named group: ffdhe4096
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.014 CEST|SupportedGroupsExtension.java:841|Ignore inactive or disabled named group: ffdhe6144
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.014 CEST|SupportedGroupsExtension.java:841|Ignore inactive or disabled named group: ffdhe8192
javax.net.ssl|WARNING|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.026 CEST|SignatureScheme.java:282|Signature algorithm, ed25519, is not supported by the underlying providers
javax.net.ssl|WARNING|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.027 CEST|SignatureScheme.java:282|Signature algorithm, ed448, is not supported by the underlying providers
javax.net.ssl|ALL|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.043 CEST|SignatureScheme.java:358|Ignore disabled signature sheme: rsa_md5
javax.net.ssl|INFO|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.046 CEST|AlpnExtension.java:161|No available application protocols
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.047 CEST|SSLExtensions.java:256|Ignore, context unavailable extension: application_layer_protocol_negotiation
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.053 CEST|ClientHello.java:651|Produced ClientHello handshake message (
"ClientHello": {
"client version" : "TLSv1.2",
"random" : "4D 37 59 83 17 36 AD CD 4E D5 4F DB EF 60 88 66 23 B2 ED FA DC 13 81 EF 5D 19 9E DC 9E FA 41 57",
"session id" : "",
"cipher suites" : "[TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), TLS_RSA_WITH_AES_256_CBC_SHA(0x0035)]",
"compression methods" : "00",
"extensions" : [
]
}
)
15:44:51.076 [epollEventLoopGroup-2-1] DEBUG io.netty.util.Recycler - -Dio.netty.recycler.maxCapacityPerThread: 4096
15:44:51.077 [epollEventLoopGroup-2-1] DEBUG io.netty.util.Recycler - -Dio.netty.recycler.maxSharedCapacityFactor: 2
15:44:51.078 [epollEventLoopGroup-2-1] DEBUG io.netty.util.Recycler - -Dio.netty.recycler.linkCapacity: 16
15:44:51.078 [epollEventLoopGroup-2-1] DEBUG io.netty.util.Recycler - -Dio.netty.recycler.ratio: 8
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.135 CEST|SSLEngineOutputRecord.java:507|WRITE: TLS12 handshake, length = 223
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.136 CEST|SSLEngineOutputRecord.java:525|Raw write (...)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.176 CEST|SSLEngineInputRecord.java:177|Raw read (...)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.177 CEST|SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 93
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.184 CEST|ServerHello.java:866|Consuming ServerHello handshake message (
"ServerHello": {
"server version" : "TLSv1.2",
"random" : "EC 44 2C 42 7F C7 DD 1F C5 F8 C2 E1 13 4B C1 94 71 41 AF EF 96 E1 8D F3 E8 B4 7B 11 D7 74 A1 3F",
"session id" : "37 23 36 B1 49 8B A1 97 C5 2C F0 3A BC 25 D4 BF 13 3D 25 35 A9 31 C0 3E AB DA CE 81 E2 39 4D FF",
"cipher suite" : "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F)",
"compression methods" : "00",
"extensions" : [
"renegotiation_info (65,281)": {
"renegotiated connection": [<no renegotiated connection>]
},
"ec_point_formats (11)": {
"formats": [uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2]
},
"extended_master_secret (23)": {
<empty>
}
]
}
)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.185 CEST|SSLExtensions.java:169|Ignore unavailable extension: supported_versions
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.186 CEST|ServerHello.java:962|Negotiated protocol version: TLSv1.2
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.187 CEST|SSLExtensions.java:188|Consumed extension: renegotiation_info
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.188 CEST|SSLExtensions.java:169|Ignore unavailable extension: server_name
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.189 CEST|SSLExtensions.java:169|Ignore unavailable extension: max_fragment_length
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.189 CEST|SSLExtensions.java:169|Ignore unavailable extension: status_request
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.191 CEST|SSLExtensions.java:188|Consumed extension: ec_point_formats
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.194 CEST|SSLExtensions.java:169|Ignore unavailable extension: status_request_v2
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.194 CEST|SSLExtensions.java:188|Consumed extension: extended_master_secret
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.195 CEST|SSLExtensions.java:188|Consumed extension: renegotiation_info
javax.net.ssl|ALL|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.195 CEST|SSLSessionImpl.java:209|Session initialized: Session(1571147091195|TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.196 CEST|SSLExtensions.java:203|Ignore unavailable extension: server_name
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.196 CEST|SSLExtensions.java:203|Ignore unavailable extension: max_fragment_length
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.196 CEST|SSLExtensions.java:203|Ignore unavailable extension: status_request
javax.net.ssl|WARNING|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.197 CEST|SSLExtensions.java:211|Ignore impact of unsupported extension: ec_point_formats
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.197 CEST|SSLExtensions.java:203|Ignore unavailable extension: application_layer_protocol_negotiation
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.197 CEST|SSLExtensions.java:203|Ignore unavailable extension: status_request_v2
javax.net.ssl|WARNING|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.197 CEST|SSLExtensions.java:211|Ignore impact of unsupported extension: extended_master_secret
javax.net.ssl|WARNING|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.198 CEST|SSLExtensions.java:211|Ignore impact of unsupported extension: renegotiation_info
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.209 CEST|SSLEngineInputRecord.java:177|Raw read (...)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.215 CEST|SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 2517
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.240 CEST|CertificateMessage.java:358|Consuming server Certificate handshake message (
"Certificates": [...]
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.760 CEST|X509TrustManagerImpl.java:300|Found trusted certificate (
"certificate" : {...}
)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.766 CEST|SSLEngineInputRecord.java:177|Raw read (...)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.767 CEST|SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 333
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.778 CEST|ECDHServerKeyExchange.java:538|Consuming ECDH ServerKeyExchange handshake message (
"ECDH ServerKeyExchange": {
"parameters": {
"named group": "secp256r1"
"ecdh public": {...},
},
"digital signature": {
"signature algorithm": "rsa_pss_rsae_sha256"
"signature": {...},
}
}
)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.780 CEST|SSLEngineInputRecord.java:177|Raw read (...)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.782 CEST|SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 131
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.788 CEST|CertificateRequest.java:651|Consuming CertificateRequest handshake message (
"CertificateRequest": {
"certificate types": [rsa_sign, dss_sign, ecdsa_sign]
"supported signature algorithms": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, ed25519, ed448, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha224, ecdsa_sha1, rsa_sha224, rsa_pkcs1_sha1, dsa_sha224, dsa_sha1, dsa_sha256, dsa_sha384, dsa_sha512]
"certificate authorities": [CN=ca.your-server.de, CN=ca.dev-broker.your-server.de]
}
)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:51.812 CEST|X509KeyManagerImpl.java:389|KeyMgr: choosing key: 1 (verified: OK)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.131 CEST|SSLEngineInputRecord.java:177|Raw read (
0000: 16 03 03 00 04 0E 00 00 00 .........
)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.131 CEST|SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 4
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.132 CEST|ServerHelloDone.java:142|Consuming ServerHelloDone handshake message (
<empty>
)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.141 CEST|CertificateMessage.java:322|Produced client Certificate handshake message (
"Certificates": [
"certificate" : {...}
]
)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.150 CEST|ECDHClientKeyExchange.java:401|Produced ECDHE ClientKeyExchange handshake message (
"ECDH ClientKeyExchange": {
"ecdh public": {...},
}
)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.387 CEST|CertificateVerify.java:743|Produced CertificateVerify handshake message (
"CertificateVerify": {
"signature algorithm": rsa_pss_rsae_sha256
"signature": {...}
}
)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.418 CEST|ChangeCipherSpec.java:109|Produced ChangeCipherSpec message
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.419 CEST|Finished.java:395|Produced client Finished handshake message (
"Finished": {
"verify data": {
...
}'}
)
avax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.422 CEST|SSLEngineOutputRecord.java:507|WRITE: TLS12 handshake, length = 2855
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.427 CEST|SSLEngineOutputRecord.java:525|Raw write (...)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.430 CEST|SSLEngineOutputRecord.java:507|WRITE: TLS12 change_cipher_spec, length = 1
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.431 CEST|SSLEngineOutputRecord.java:525|Raw write (
0000: 14 03 03 00 01 01 ......
)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.432 CEST|SSLEngineOutputRecord.java:507|WRITE: TLS12 handshake, length = 16
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.483 CEST|SSLCipher.java:1727|Plaintext before ENCRYPTION (
0000: 14 00 00 0C 91 F1 79 2C A0 3C A8 61 58 45 99 AF ......y,.<.aXE..
)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.487 CEST|SSLEngineOutputRecord.java:525|Raw write (
0000: 16 03 03 00 28 00 00 00 00 00 00 00 00 09 AE 57 ....(..........W
0010: EC 20 A9 DD 8F 44 DE 34 3D BE F8 44 F8 D9 7D F0 . ...D.4=..D....
0020: 3F C1 62 92 97 40 2C BD 44 38 E0 8A 7E ?.b..#,.D8...
)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.504 CEST|SSLEngineInputRecord.java:177|Raw read (
0000: 14 03 03 00 01 01 ......
)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.505 CEST|SSLEngineInputRecord.java:214|READ: TLSv1.2 change_cipher_spec, length = 1
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.505 CEST|ChangeCipherSpec.java:143|Consuming ChangeCipherSpec message
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.509 CEST|SSLEngineInputRecord.java:177|Raw read (
0000: 16 03 03 00 28 FF 2B 4B EC 5F F7 5C BA 8C 2F 34 ....(.+K._.\../4
0010: 2A C1 FE 1C 6F 92 22 BC B2 B4 E8 93 3C F2 20 48 *...o.".....<. H
0020: 8E FE E2 60 93 7A 3D EA B3 FA 66 05 F2 ...`.z=...f..
)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.510 CEST|SSLEngineInputRecord.java:214|READ: TLSv1.2 handshake, length = 40
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.514 CEST|SSLCipher.java:1629|Plaintext after DECRYPTION (
0000: 14 00 00 0C AB A5 7E 92 19 0D F5 96 FA E2 D5 A4 ................
)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.547 CEST|Finished.java:532|Consuming server Finished handshake message (
"Finished": {
"verify data": {
0000: AB A5 7E 92 19 0D F5 96 FA E2 D5 A4
}'}
)
15:44:52.586 [epollEventLoopGroup-2-1] DEBUG io.netty.handler.ssl.SslHandler - [id: 0xf55e3747, L:/10.156.123.175:40054 - R:dev-broker.your-server.de/185.201.147.157:8883] HANDSHAKEN: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.591 CEST|SSLEngineOutputRecord.java:267|WRITE: TLS12 application_data, length = 30
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.592 CEST|SSLCipher.java:1727|Plaintext before ENCRYPTION (
0000: 10 1C 00 04 4D 51 54 54 05 02 00 3C 00 00 0F 63 ....MQTT...<...c
0010: 6F 6E 6E 65 63 74 69 6F 6E 2D 74 65 73 74 onnection-test
)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.595 CEST|SSLEngineOutputRecord.java:283|Raw write (
0000: 17 03 03 00 36 00 00 00 00 00 00 00 01 F8 AA 69 ....6..........i
0010: 92 64 CE 34 D2 5D 5A D1 4F 4D D3 34 D8 05 5A F2 .d.4.]Z.OM.4..Z.
0020: C0 8E 63 8B 5A 51 E6 4A 4A A5 B0 E7 61 62 E5 69 ..c.ZQ.JJ...ab.i
0030: 67 84 31 16 09 59 C5 6A 76 4C E1 g.1..Y.jvL.
)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.596 CEST|SSLEngineInputRecord.java:177|Raw read (
0000: 15 03 03 00 1A FF 2B 4B EC 5F F7 5C BB 9D 2E 7B ......+K._.\....
0010: FC DB 74 D3 A3 62 BF 86 66 8B 9C 03 04 55 93 ..t..b..f....U.
)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.596 CEST|SSLEngineInputRecord.java:214|READ: TLSv1.2 alert, length = 26
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.598 CEST|SSLCipher.java:1629|Plaintext after DECRYPTION (
0000: 01 00 ..
)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.600 CEST|Alert.java:232|Received alert message (
"Alert": {
"level" : "warning",
"description": "close_notify"
}
)
javax.net.ssl|WARNING|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.602 CEST|SSLEngineOutputRecord.java:168|outbound has closed, ignore outbound application data
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.603 CEST|SSLEngineOutputRecord.java:507|WRITE: TLS12 alert, length = 2
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.604 CEST|SSLCipher.java:1727|Plaintext before ENCRYPTION (
0000: 01 00 ..
)
javax.net.ssl|DEBUG|19|epollEventLoopGroup-2-1|2019-10-15 15:44:52.609 CEST|SSLEngineOutputRecord.java:525|Raw write (
0000: 15 03 03 00 1A 00 00 00 00 00 00 00 02 30 1D 82 .............0..
0010: 69 FE 1A 9E BE 35 47 37 9E 67 DF 85 5A F4 E5 i....5G7.g..Z..
)
15:44:52.631 [epollEventLoopGroup-2-1] INFO com.you.mqtt.ConnectionListener - Disconnected from MQTT broker.
15:44:52.641 [epollEventLoopGroup-2-1] ERROR com.you.mqtt.ConnectionListener - Server closed connection without DISCONNECT. Will try to reconnect.
15:44:52.666 [RxComputationThreadPool-1] ERROR com.you.mqtt.MqttConnector - connection exception
com.hivemq.client.mqtt.exceptions.ConnectionClosedException: Server closed connection without DISCONNECT.
I'm using Java 11 with the HiveMQ MQTT client version 1.1.2 (latest in maven repo).
The server is a HAProxy, the port is 8883.
I would be really thankful, if someone has a hint or a clue about what is happening here and why the client does not connect to the the MQTT broker behind the HAProxy.
HAProxy Config
The following snippet is the part of the haproxy configuration concerned with TCP connection. The configuration follows recommendations for the VerneMQ broker.
global
daemon
user haproxy
group haproxy
chroot /var/empty
maxconn 20000
#log gi18hd.stackhero-network.com:514 local1 debug
log /dev/log local0 debug
#ssl
tune.ssl.default-dh-param 2048
#ssl-default-bind-options no-sslv3 no-tls-tickets force-tlsv12
#ssl-default-bind-ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
defaults
log global
#option httplog
option tcplog
timeout connect 5s
timeout client 30s
timeout client-fin 30s
timeout server 300s
timeout tunnel 1h
frontend front_tcp
mode tcp
option clitcpka # For TCP keep-alive
log global
option tcplog
bind *:8883 ssl crt-list /etc/haproxy/server-dev-test-crt-list.txt
use_backend sub_dev-broker if { ssl_fc_sni -i dev-broker.your-server.de }
backend sub_dev-broker
mode tcp
option redispatch
balance leastconn
server manager1 10.1.2.51:1883 check fall 1
server manager2 10.1.2.52:1883 check fall 1
server manager3 10.1.2.53:1883 check fall 1
VerneMQ Config
Our broker is a clustered(!) VerneMQ MQTT broker (https://vernemq.com/) in a Docker Swarm. The MQTT 5 protocol is enabled via the env variable DOCKER_VERNEMQ_LISTENER__TCP__ALLOWED_PROTOCOL_VERSIONS=3,4,5.
We use an internal listener on port 18883, which is mapped outside the container to 1883. Again: this setup is working with tools like MQTTFx and other Paho-based MQTT3 clients.
The corresponding docker-compose configuration is:
version: '3.7'
services:
mqttbroker0:
image: erlio/docker-vernemq
networks:
- your-backend
environment:
- DOCKER_VERNEMQ_SWARM=1
- DOCKER_VERNEMQ_ALLOW_ANONYMOUS=on
- DOCKER_VERNEMQ_LOG__CONSOLE__LEVEL=debug
mqttbroker:
image: erlio/docker-vernemq
depends_on:
- mqttbroker0
networks:
- your-backend
environment:
- DOCKER_VERNEMQ_SWARM=1
- DOCKER_VERNEMQ_DISCOVERY_NODE=mqttbroker0
- DOCKER_VERNEMQ_ALLOW_ANONYMOUS=on
- DOCKER_NET_INTERFACE=eth1
- DOCKER_VERNEMQ_LOG__CONSOLE__LEVEL=debug
- DOCKER_VERNEMQ_LISTENER__TCP__SERVER = 0.0.0.0:18883
- DOCKER_VERNEMQ_LISTENER__TCP__ALLOWED_PROTOCOL_VERSIONS=3,4,5
ports:
- "1883:18883"
deploy:
replicas: 2
networks:
your-backend:
external: true
Update: TLS handshake is ok, haproxy can't find the server
The connection is closed after the handshake between client and server. HAProxy logs
front_tcp~ front_tcp/<NOSRV> -1/-1/965 0 SC 2/1/0/0/0 0/0
We have a condition in our haproxy configuration: use_backend sub_dev-broker if { ssl_fc_sni -i dev-broker.your-server.de }. This enables us to use only one haproxy instance and to switch between different endpoints (DEV and TEST servers in our case).
The request coming from the client after the handshake can not be routed to a backend server. HAProxy reacts with NOSRV. It seems that the request does not contain the hostname of the server, so the if-condition fails.
Update: HiveMQ Client 1.1.2 does not use SNI
The HiveMQ Client 1.1.2 does not use the Server Name Indication TLS extension, Milestone 1.1.3 does. We use the SNI information for the switch in our HAProxy configuration. As I see no workaround at the moment and this functionality is not critical in the MQTT subscriber, I will wait for the next release of the HiveMQ client.
Thank you to all participants for thoughts and hints!
As I understand the provided log, there seems to be nothing wrong with the TLS handshake.
After the handshake is finished the client sends a MQTT CONNECT packet. As you are using the HiveMQ client with MQTT 5 as protocol version, this will contain a flag that MQTT 5 is expected.
Now if the used broker can't handle that, it will close the connection (protocol error).
This would also explain, why you were successful in connecting
with MQTTFx and with a MQTT3 Paho.
Alternatively you could change the MQTT client creation to:
return MqttClient.builder()
...
.useMqttVersion3()
.buildAsync();
But as your original goal was to use the shared subscriptions a broker change/upgrade would still be necessary.
Could you perhaps provide more information about the used broker?

How to retrieve the TLS root CA certificate using Indy and OpenSSL

is it possible to retrieve the TLS root CA certificate from a server using Indy and OpenSSL? I already posted this in the (German) Delphi-Praxis http://www.delphipraxis.net/190534-indy-openssl-komplette-zertifikatskette-im-client-ermitteln.html
but got no answer there.
I need to retrieve the whole certificate chain of the server's certificate in order to display it to the user. I do not want to add a bunch of trusted CAs (and keep the list up to date) as probably most of the servers I will deal with will either have self-signed certificates or enterprise internal CAs.
This is the output of my program when accessing mail.startcom.org. I think in my output there is missing the root CA ("/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority")
*** Got certificate. Depth = 1, Error = 20
Subject: /C=IL/O=StartCom Ltd./OU=StartCom Certification Authority/CN=StartCom Class 3 OV Server CA
Issuer: /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
SHA1 Fingerprint: 5A:F7:D2:E0:80:5E:1C:7B:E5:74:22:F3:5E:63:6B:25:94:47:E5:D7
*** Got certificate. Depth = 0, Error = 20
Subject: /C=IL/ST=HaDarom/L=Eilat/O=StartCom Ltd. (Start Commercial Limited)/CN=mail.startcom.org
Issuer: /C=IL/O=StartCom Ltd./OU=StartCom Certification Authority/CN=StartCom Class 3 OV Server CA
SHA1 Fingerprint: F2:65:56:CD:A7:41:73:D8:FE:B6:85:4F:D8:79:E4:BA:3F:4D:78:C7
EIdConnClosedGracefully: Connection Closed Gracefully.
Th openSSL version I used is 1.0.2j and the indy version is the one bundled with Delphi XE2. Compiling the application with 10.1 berlin (and the indy version bundled with) shows the same behaviour.
Here is the code of my sample application:
unit Unit1;
interface
uses
Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls,
IdSmtp, IdSSLOpenSSL, IdExplicitTLSClientServerBase;
type
TForm1 = class(TForm)
btnGetCertChain: TButton;
Memo1: TMemo;
chkCancelTlsHandshake: TCheckBox;
editHost: TEdit;
editPort: TEdit;
procedure btnGetCertChainClick(Sender: TObject);
function TlsVerifyPeer(Certificate: TIdX509;
AOk: Boolean; ADepth, AError: Integer): Boolean;
procedure FormCreate(Sender: TObject);
procedure FormDestroy(Sender: TObject);
private
FSMTPClient: TIdSMTP;
procedure InitTls();
end;
var
Form1: TForm1;
implementation
{$R *.dfm}
procedure TForm1.btnGetCertChainClick(Sender: TObject);
begin
memo1.Clear();
Memo1.Lines.Add('Trying to connect to ' + editHost.Text + '.' + editPort.Text);
FSMTPClient.Host := editHost.Text;//'mail.startcom.org';
FSmtpClient.Port := StrToIntDef(editPort.Text, -1);//25;
try
FSmtpClient.Connect();
FSMTPClient.Authenticate(); // calls StartTLS
except
on E: Exception do
begin
// when we "cancel" the handshake, there will be an exception...
Memo1.Lines.Add(E.ClassName + ': ' + E.Message);
end;
end;
FSmtpClient.Disconnect();
end;
procedure TForm1.FormCreate(Sender: TObject);
begin
FSMTPClient := TIdSMTP.Create(nil);
InitTls();
end;
procedure TForm1.FormDestroy(Sender: TObject);
begin
FreeAndNil(FSMTPClient);
end;
procedure TForm1.InitTls;
var
SslIoHandler: TIdSSLIOHandlerSocketOpenSSL;
begin
SslIoHandler := TIdSSLIOHandlerSocketOpenSSL.Create(FSMTPClient);
SslIoHandler.SSLOptions.Method := sslvTLSv1;
SslIoHandler.SSLOptions.VerifyMode := [sslvrfPeer];
SslIoHandler.SSLOptions.VerifyDepth := 9; // 9 is default: https://linux.die.net/man/3/ssl_ctx_set_verify_depth
// SslIoHandler.SSLOptions.RootCertFile ; // don't have one
SslIoHandler.OnVerifyPeer := TlsVerifyPeer; // Necessary for certificate verification
FSMTPClient.IOHandler := SslIoHandler; // ownership of SslIoHandler is moved
FSMTPClient.UseTLS := utUseRequireTLS;
end;
function TForm1.TlsVerifyPeer(Certificate: TIdX509; AOk: Boolean; ADepth,
AError: Integer): Boolean;
begin
// store/output certificate info... or just output for demonstrational purpose
Memo1.Lines.Add('');
Memo1.Lines.Add('*** Got certificate. Depth = ' + inttostr(ADepth)+', Error = ' + IntToStr(AError));
Memo1.Lines.Add(' Subject: ' + Certificate.Subject.OneLine);
Memo1.Lines.Add(' Issuer: ' + Certificate.Issuer.OneLine);
Memo1.Lines.Add(' SHA1 Fingerprint: ' + Certificate.Fingerprints.SHA1AsString);
result := true;
if chkCancelTlsHandshake.Checked then
begin
// for now we do not want to continue - present certificates to the user first
result := ADepth > 0; // false for leaf cert; true for (intermediate) CAs
end;
end;
end.
Am I just missing a call or is this a problem with Indy/OpenSSL?
Is it possible to retrieve the TLS root CA certificate from a server using Indy and OpenSSL
The short answer with respect to PKIX is, it depends. PKIX is the Internet's PKI, and there's an IETF working group that controls it. Other PKI's may be run differently than the way the IETF runs PKIX.
On a well configured server, the server sends its end-entity certificate and all intermediate CA certificates required to build a path for validation. The server sends the intermediates to solve the PKI's which directory problem. The server does not send the Root CA because the client must already have it.
Many servers will send the Root CA too. This is usually kind of pointless because the client must get the root out-of-band and already trust it. If the client does not have the root, then a bad guy can simply swap-in his root and chain.
This is the output of my program when accessing mail.startcom.org. I think in my output there is missing the root CA ("/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority")
I can't seem to connect:
$ openssl s_client -starttls smtp -connect mail.startcom.org:25 -servername mail.startcom.org -tls1
140735103578496:error:0200203C:system library:connect:Operation timed out:crypto/bio/b_sock2.c:108:
140735103578496:error:2008A067:BIO routines:BIO_connect:connect error:crypto/bio/b_sock2.c:109:
connect:errno=60
And:
$ openssl s_client -connect mail.startcom.org:465 -servername mail.startcom.org -tls1
CONNECTED(00000003)
140735103578496:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:250:
...
StartCom appears to have a configuration problem with their email over SMTPS. Maybe that's the source of your problems. It appears they are running plain text mail over the TLS ports. Notice the response below - its a plain text mail command:
$ openssl s_client -connect mail.startcom.org:465 -servername mail.startcom.org -tls1 -debug
CONNECTED(00000003)
write to 0x7f8d1241fd70 [0x7f8d12821600] (128 bytes => 128 (0x80))
0000 - 16 03 01 00 7b 01 00 00-77 03 01 cc f5 46 b3 e3 ....{...w....F..
0010 - ef 84 0b b4 ca 05 7a 6b-e7 6f 9b d7 15 aa 80 c3 ......zk.o......
0020 - e5 4f 3d a5 76 56 1d 63-dc c1 3d 00 00 12 c0 0a .O=.vV.c..=.....
0030 - c0 14 00 39 c0 09 c0 13-00 33 00 35 00 2f 00 ff ...9.....3.5./..
0040 - 01 00 00 3c 00 00 00 16-00 14 00 00 11 6d 61 69 ...<.........mai
0050 - 6c 2e 73 74 61 72 74 63-6f 6d 2e 6f 72 67 00 0b l.startcom.org..
0060 - 00 04 03 00 01 02 00 0a-00 0a 00 08 00 1d 00 17 ................
0070 - 00 19 00 18 00 23 00 00-00 16 00 00 00 17 .....#........
0080 - <SPACES/NULS>
read from 0x7f8d1241fd70 [0x7f8d12819203] (5 bytes => 5 (0x5))
0000 - 32 32 30 20 6d 220 m
If you can get s_client to work, then it will tell you which root certificate you should use. It will be the last Issuer in the chain s_client prints (for an example, see “verify error:num=20” when connecting to gateway.sandbox.push.apple.com).
Once you know the root certificate's Distinguished Name, then you use it in OpenSSL via SSL_load_verify_locations. I don't now how to do it in Delphi.
By the way, you should usually use Server Name Indication, too. In OpenSSL, you do that with SSL_set_tlsext_host_name. I don't now how to do it in Delphi.
Once you know the root certificate's Distinguished Name, then you
use it in OpenSSL via SSL_load_verify_locations. I don't now how to
do it in Delphi.
By the way, you can download the StartCom certificates from the page Certificates and Public Key Infrastructure.

Apple push notification not working for distribution/ad hoc testing

I have been using sandbox push notification for a while, and it is working perfectly. After switching to distribution, push notification stopped working.
Things that I have checked:
Two separate push notification certificates are created, one for development (Sandbox) and one for distribution(production).
Device token is different for sandbox and production.
We use NotNoop APNS on server side. The certificate.p12 is created by exporting the private key under push notification certificate in Apple Keychain Access. Certificate itself is not in the p12 file.
Checked archived package for production with command
codesign -d --entitlements :- "Payload/YourApp.app"
And the code signing entitlement is distribution.
Followed Apple TN 2265 (https://developer.apple.com/library/ios/technotes/tn2265/_index.html). While using openssl to connect to APNS, the connection is closed right after handshake (for production). For sandbox, there is a pause after the handshake, and then more reads & writes.
My command:
> openssl pkcs12 -in Cert_prod.p12 -out Cert_prod.pem
> openssl s_client -connect gateway.push.apple.com:2195 -cert Cert_prod.pem -debug -showcerts -CAfile "Entrust.pem"
The output (for production):
...
Server certificate
subject=/C=US/ST=California/L=Cupertino/O=Apple Inc./CN=gateway.push.apple.com
issuer=/C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
---
Acceptable client certificate CA names
/C=US/O=Apple Inc./OU=Apple Certification Authority/CN=Apple Root CA
/C=US/O=Apple Inc./OU=Apple Worldwide Developer Relations/CN=Apple Worldwide Developer Relations Certification Authority
/C=US/O=Apple Inc./OU=Apple Certification Authority/CN=Apple Application Integration Certification Authority
---
SSL handshake has read 3144 bytes and written 2161 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID:
Session-ID-ctx:
Master-Key: CCCE22D7487589D257E547F2693E8AEDF86B693E6EFE09DCAA7EE74C28812E45506A21B0DC0ED6CAAF4395EB2D2899ED
Key-Arg : None
Start Time: 1454828210
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
read from 0x7fa6d3a00060 [0x7fa6d4806600] (5 bytes => 5 (0x5))
0000 - 15 03 01 ...
0005 - <SPACES/NULS>
read from 0x7fa6d3a00060 [0x7fa6d4806605] (32 bytes => 32 (0x20))
0000 - 8f c6 74 25 a6 40 2b 58-29 bc a4 e0 a7 c9 43 a8 ..t%.#+X).....C.
0010 - a0 93 62 78 6a 73 ed aa-4f 61 0a a4 9e fe a7 9e ..bxjs..Oa......
closed
write to 0x7fa6d3a00060 [0x7fa6d480b000] (37 bytes => 37 (0x25))
0000 - 15 03 01 00 20 2c 70 db-af 76 7a 2c 01 70 da 0f .... ,p..vz,.p..
0010 - a9 03 da e2 fb 69 f8 09-63 5d 18 85 81 8c 31 63 .....i..c]....1c
0020 - 63 fb 73 cb 48 c.s.H
The output (for sandbox):
...
Server certificate
subject=/C=US/ST=California/L=Cupertino/O=Apple Inc./CN=gateway.sandbox.push.apple.com
issuer=/C=US/O=Entrust, Inc./OU=www.entrust.net/rpa is incorporated by reference/OU=(c) 2009 Entrust, Inc./CN=Entrust Certification Authority - L1C
---
Acceptable client certificate CA names
/C=US/O=Apple Inc./OU=Apple Certification Authority/CN=Apple Root CA
/C=US/O=Apple Inc./OU=Apple Worldwide Developer Relations/CN=Apple Worldwide Developer Relations Certification Authority
/C=US/O=Apple Inc./OU=Apple Certification Authority/CN=Apple Application Integration Certification Authority
---
SSL handshake has read 3160 bytes and written 2161 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID:
Session-ID-ctx:
Master-Key: 011B90857BC02D4A9DCB7300F8C9F368905F90EA4BDDC0677CD2EA9AAB3550CF750F0B57C5AF0C72F5BCD991658AC4AC
Key-Arg : None
Start Time: 1454828396
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
write to 0x7f9b19c1aef0 [0x7f9b1a019000] (74 bytes => 74 (0x4A))
0000 - 17 03 01 00 20 d7 a1 a1-b2 9e be ce 49 18 26 0e .... .......I.&.
0010 - 46 73 f9 dc 7f b2 75 71-f6 bf 51 65 44 0e f1 60 Fs....uq..QeD..`
0020 - fe 80 2e e2 a6 17 03 01-00 20 f0 be dc 70 85 b0 ......... ...p..
0030 - 82 d0 44 1e 9a b8 fe 59-39 b1 14 be 0a 9d 7c 0e ..D....Y9.....|.
0040 - ce 09 9b c3 f2 1c dd 28-c7 24 .......(.$
write to 0x7f9b19c1aef0 [0x7f9b1a019000] (74 bytes => 74 (0x4A))
0000 - 17 03 01 00 20 4c 12 4f-f9 ba 0b e4 80 b3 66 bb .... L.O......f.
0010 - 93 a7 c9 47 9d 84 36 88-33 c0 80 79 a2 97 c6 95 ...G..6.3..y....
0020 - 2a 4b 42 c1 bc 17 03 01-00 20 a0 4d 06 fd 84 78 *KB...... .M...x
0030 - 3d b9 12 ad 65 75 b6 1a-01 91 28 86 40 c4 e9 c2 =...eu....(.#...
0040 - 38 91 47 42 c3 1d e3 c7-f9 41 8.GB.....A
write to 0x7f9b19c1aef0 [0x7f9b1a019000] (74 bytes => 74 (0x4A))
0000 - 17 03 01 00 20 35 77 28-ea b0 80 5a ad 9e 99 87 .... 5w(...Z....
0010 - 7d 07 13 14 ff ea a8 48-60 7c 46 f0 59 07 c8 53 }......H`|F.Y..S
0020 - 3f 96 55 fc ec 17 03 01-00 20 60 49 00 86 bf 41 ?.U...... `I...A
0030 - 70 70 5c d5 d7 f5 83 4c-8a b3 10 22 bb ad 4c f2 pp\....L..."..L.
0040 - 3e e0 54 db 5d e7 2e bc-cc 9c >.T.].....
write to 0x7f9b19c1aef0 [0x7f9b1a019000] (74 bytes => 74 (0x4A))
0000 - 17 03 01 00 20 25 d3 8a-20 a4 4c 3c b6 f7 fe 95 .... %.. .L<....
0010 - 60 e2 5b 9f fc fd 3d e7-4c 27 cc d0 8e 6c ef 30 `.[...=.L'...l.0
0020 - 56 4a 88 a9 f9 17 03 01-00 20 cc 32 2d d5 e6 ff VJ....... .2-...
0030 - 59 26 14 67 2d 3f 3d 88-d3 3b ea 53 5e 11 72 75 Y&.g-?=..;.S^.ru
0040 - a4 c6 0e d8 95 b4 21 e3-5d dd ......!.].
write to 0x7f9b19c1aef0 [0x7f9b1a019000] (74 bytes => 74 (0x4A))
0000 - 17 03 01 00 20 8a a0 b6-fd 72 7b f4 f6 ef de 65 .... ....r{....e
0010 - 76 40 6b 67 1d b8 83 c1-92 98 50 9e 0f ac d7 da v#kg......P.....
0020 - 66 39 9c 39 9f 17 03 01-00 20 70 a4 1d 63 f1 6e f9.9..... p..c.n
0030 - d6 5a b3 fd f9 7e de de-64 7d 42 0d da 94 59 09 .Z...~..d}B...Y.
0040 - 93 3f 33 e3 d7 d0 3e 2e-10 e7 .?3...>...
read from 0x7f9b19c1aef0 [0x7f9b1a014600] (5 bytes => 5 (0x5))
0000 - 15 03 01 ...
0005 - <SPACES/NULS>
read from 0x7f9b19c1aef0 [0x7f9b1a014605] (32 bytes => 32 (0x20))
0000 - 60 b6 57 1c 8a 8e e9 f0-59 b5 27 73 f5 ba de b1 `.W.....Y.'s....
0010 - 7a ef d7 ab 79 23 0a ea-b2 13 c9 ca 98 e5 c3 36 z...y#.........6
closed
write to 0x7f9b19c1aef0 [0x7f9b1a019000] (37 bytes => 37 (0x25))
0000 - 15 03 01 00 20 f2 6f d0-1b 8d 41 5e 44 df f5 49 .... .o...A^D..I
0010 - 3a 09 6a 11 2b 3b f3 47-1e 70 8d 8d a8 9d 42 45 :.j.+;.G.p....BE
0020 - e9 47 18 26 3e .G.&>
Therefore, it seems that the broken link is between my server and APNS. How can I know why the connection is closed?
I suspected that something is wrong on the certificate, but could not find anything. I took the same steps to create sandbox certificates, and they worked just fine. Did I miss anything for production?
Other related links that I checked:
apple push notification not working in production
http://www.raywenderlich.com/32960/apple-push-notification-services-in-ios-6-tutorial-part-1
Couldn't able to connect to APNS Sandbox server
The certificate.p12 in NotNoop APNS should be exported from the certificate only, without the private key. In Keychain Access, click the small arrow next to the push notification certificate to show the private key, select the certificate only (without the key), and export it to a .p12 file. Updating the file on server solved my problem. Openssl is a good tool for smoke test before archiving the app and running it in ad hoc mode.

Trouble using a SSL certificate: 'self signed certificate in certificate chain'

I am using a self generated wildcard SSL certificate and I would like to know if the following is a problem and, if so, what I can do to fix that. Certificate is for my web Ruby on Rails 3 application running on localhost.
I am using a Mac OS running "Snow Leopard" 1.6.6. Typing in the Terminal
<my_user_name>$ openssl s_client -connect localhost.com:443
I get the following:
CONNECTED(00000003)
depth=1 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = My Name\Surname
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=*localhost.com
i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=My Name\Surname
1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=My Name\Surname
i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=My Name\Surname
---
Server certificate
-----BEGIN CERTIFICATE-----
MIICJDCCAY0CAQEwDQYJKoZIhvcNAQEEBQAwWTELMAkGA1UEBhMCQVUxEzARBgNV
BAgMClNvbWUtU3RhdGUxITAfBgNVBAoMGEludGVybmV0IFdpZGdpdHMgUHR5IEx0
ZDESMBAGA1UEAwwJU2VyZ2lvIEwuMB4XDTExMDIxODIwMDAwOFoXDTEyMDIxODIw
MDAwOFowXDELMAkGA1UEBhMCQVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNV
BAoMGEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDEVMBMGA1UEAwwMKnBqdG5hbWUu
Y29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDM46dH9rWKy5sNKBwJ7oo
wytsjw8fFLRskJGE0QqgKpz5ZtYK8yC/kifI4gpWZYVySePmVqHR6+wpv8Ry1KVx
Bl2qhF6ssLBbc5bvOK4eF2Rx9LNAZ/ndy+0q07DVsnAMMCxhNmegltCG1JZhazCG
g7elPm2pIQLAQvKlFSJwkQIDAQABMA0GCSqGSIb3DQEBBAUAA4GBADO7XJbOASZM
Bm/XElq1AuVU1dR6/wkowLOxCn8+KWsUmyIdZj1yL8+83nhhG/yekzOr25n/I0SQ
zN1aUi3oX5vXlx8vp2xQsnug2BM/InfQxOn+90JjhZYPbCokH9ifzYsNj7fvGg57
KZ4et2jSfchxFMRqqoPutdOp/gNKw3me
-----END CERTIFICATE-----
subject=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=*localhost.com
issuer=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=My Name\Surname
---
No client certificate CA names sent
---
SSL handshake has read 1944 bytes and written 409 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 63BE474E62950D542BCBE30F72F80C28851EE23EA15BA34AE3E3E46AB5615505
Session-ID-ctx:
Master-Key: 9E8A8F7F4E824A2B251D5A28E3A133AC761BA8EDB237073973D2B1AE0AE0A31ADDADA2315F33B443B3F29D382070FC6C
Key-Arg : None
PSK identity: None
PSK identity hint: None
TLS session ticket:
0000 - 10 b0 f3 4d 96 90 d3 65-22 d4 bf 09 27 8c a0 af ...M...e"...'...
0010 - d3 79 5c 9a cf d9 5b e1-3f aa 46 56 55 9b 55 50 .y\...[.?.FVU.UP
0020 - 8b 49 99 07 bc 35 e0 bc-e1 1d 4e 61 f0 aa 33 57 .I...5....Na..3W
0030 - 1d 37 0b dd 51 ae 81 ea-df 8e 6e 25 ff f7 2b ff .7..Q.....n%..+.
0040 - e9 88 79 e4 57 2a b2 f2-61 22 df 86 f0 24 57 a7 ..y.W*..a"...$W.
0050 - 06 13 b5 71 47 dc d5 ac-c2 61 89 75 6e 03 45 cc ...qG....a.un.E.
0060 - 14 69 0c 72 3a 4a 00 b3-4f d8 8d 44 2d 66 cb 40 .i.r:J..O..D-f.#
0070 - 80 c8 9b e2 12 9f 0d b4-58 6e a1 c7 bb fe 92 6d ........Xn.....m
0080 - b8 b7 b7 f0 dc 1c ab fd-44 a4 25 96 c6 09 09 a1 ........D.%.....
0090 - aa ff c0 dc 53 6b 30 13-30 f3 44 f6 78 b1 43 c7 ....Sk0.0.D.x.C.
00a0 - ca 88 9d 63 41 d3 c1 a1-af fa 36 e2 9c fd 0e 62 ...cA.....6....b
00b0 - c4 44 6b 5c 74 da ff be-a8 98 3f 54 f9 fa 59 15 .Dk\t.....?T..Y.
Compression: 1 (zlib compression)
Start Time: 1298072476
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
The issue, maybe, is on line 3: verify error:num=19:self signed certificate in certificate chain. What that means? Is my certificate working for localhost.com?
UPDATE
In browser I accepted my sel-signed certificate (I explicitly added my certificate to the list of private certificates in the system), so, even I get verify error:num=19:self signed certificate in certificate chain and in my application I use the following code to make HTTP requests over SSL
require 'uri'
require 'net/https'
host = "https://<subdomain>.localhost.com"
path = "/users/1.json"
uri = URI.parse("#{host}#{path}")
http = Net::HTTP.new(uri.host, uri.port)
http.use_ssl = true
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
# I think here is necessary to verify connections using 'http.verify_mode = OpenSSL::SSL::VERIFY_PEER':
# in localhost using that the connection will fault, but in production mode
# (when I will deploy the application) I think I MUST use 'VERIFY_PEER'
http.ca_file = File.join(File.dirname("<certificate_folder>/wildcard.certificate/ca.db.certs/"), "01.pem")
http.start do
response = http.get("#{host}#{path}")
#test_response = JSON(response.body)["profile"]
end
the connection is actually going over SSL? 'VERIFY_PEER' means something?
SSL verifies the validity of a host by checking the certificate of the host.
Every certificate is either:
Self-Signed
Signed by another certificate.
If it is signed by another certificate, it checks the certificate that signed it.
Now, at some point, to verify if a certificate is valid or not, it has to match that certificate against a store of 'valid' certificates it has on the system (Eg: Firefox maintains its own store, Windows has its own store, etc.). If it matches some certificate in the hierarchy against the store, then it treats that certificate as valid, and therefore all certificates signed by it are valid.
However, if the certificate is self-signed and isn't in the store, then it will reject it, or warn you that it cannot verify the certificate.
If the certificate is for you to test out an application, or for a very limited scale deployment where you can ask people to add your certificate to their store, this is alright. However, if you are planning to move your application to a production site at somedomain.com, then you will probably need to buy a certificate for that domain.
Note: in either case, the self-signed certificate you have for localhost is valid only for 'localhost', not even if it is accessed on an intranet via IP
The purpose of certificates [in SSL] is to prove that the host is the one it claims to be and not the fake one. To do this certificates are issued by certificate authorities, who [are supposed to properly] check the identity of the person or organization that requests a certificate. Consequently, self-signed certificate doesn't reliably identify the host (even if it's a localhost). So most applications report a validation error when they see a self-signed certificate in a chain of certificates. The only exception is [usually] when the certificate is explicitly added to the list of private certificates in the system - in this case it's accepted as valid.
Consequently, if you have created your self-signed certificate for test purposes on your computer, then you can add it to trusted list. Otherwise (if you need a certificate for a public host), you will need to buy a certificate from one of certificate authorities.

Resources