ESP32 MQTT with TLS not working with NATS MQTT - c++

Hi i have a project about connect ESP32 to NATS via MQTT
After I try --insecurity it work normally.
But when I add TLS it doesn't work in my ESP32, i also try with Python it work normally with my self-signed SSL certificate.
I already find solution from here but it not work: https://github.com/espressif/arduino-esp32/issues/5021
My idea code get from here: https://github.com/debsahu/ESP-MQTT-AWS-IoT-Core/blob/master/Arduino/PubSubClient/PubSubClient.ino
Is MQTT TLS in ESP32 not work with self-signed cert or I done something wrong ?
Cert TLS:
"-----BEGIN CERTIFICATE-----\n"
"MIID8TCCAtmgAwIBAgIUfceZXKK1JIqHi57rc98EBmJoy1kwDQYJKoZIhvcNAQEL\n"
"BQAwgYcxCzAJBgNVBAYTAlZOMRAwDgYDVQQIDAd2aWV0bmFtMRAwDgYDVQQHDAd2\n"
"aWV0bmFtMQ4wDAYDVQQKDAVwZWNvbTENMAsGA1UECwwEdGVzdDENMAsGA1UEAwwE\n"
"bXF0dDEmMCQGCSqGSIb3DQEJARYXY3B0cHJpY2UxMjNAb3V0bG9vay5jb20wHhcN\n"
"MjIxMTAzMDgxMDEzWhcNMjMxMTAzMDgxMDEzWjCBhzELMAkGA1UEBhMCVk4xEDAO\n"
"BgNVBAgMB3ZpZXRuYW0xEDAOBgNVBAcMB3ZpZXRuYW0xDjAMBgNVBAoMBXBlY29t\n"
"MQ0wCwYDVQQLDAR0ZXN0MQ0wCwYDVQQDDARtcXR0MSYwJAYJKoZIhvcNAQkBFhdj\n"
"cHRwcmljZTEyM0BvdXRsb29rLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC\n"
"AQoCggEBALRTuKn8m1QuFJI3THb2rkEiKPHD/cdRs/E1Vb96GIBSy4D/s8vJ2OWd\n"
"GHlbLK557OpAH7JrRg6tVEVVr3293u8imwDIcNyOHlBYWSO/DBKGXsoCbOL1u6Gd\n"
"zAn/G+96eX3RUIHRbBF/rE6DZS5Y1Piq7FwdaReHSZhMPB+UMB4xUEC3pC6CzqFt\n"
"xjudk9zT5VpR60XiJAls3YtYpUu4zRZUw2Sb1ZsPmT555QFYbOcF4XlC82MVi/o3\n"
"M91LJ8DyiOvNWxuioIT2frEyIXaTleug3Ev0ALiu8ug9/v/zTWZWq3KA98HZJcm+\n"
"Hr8dChlMewpMpabEi1e0twlzTPw9QyMCAwEAAaNTMFEwHQYDVR0OBBYEFE3SQ0F5\n"
"yzsBkHUcFp/KucgyGHpWMB8GA1UdIwQYMBaAFE3SQ0F5yzsBkHUcFp/KucgyGHpW\n"
"MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAC+pjnAd9c71DfCv\n"
"RUMvYg93mraaqtoEw22ggtT9AfIZfI+o8L5Nxk5us+9k9IBEP4hi6DHtnFxqfFt8\n"
"YkzNNDMTDvLfg/1INUwg8yBYS9Z2+puoPlPTvaxOJiuz2+DkYV/LnUdTolKPqYrO\n"
"IBIbmwMNz0Bqn1XZ7Mjx9U7p+A2N/87NGl3fo0I0tWBRSGXFZB7IYipgCPQG5Eb+\n"
"ZL9vrgFuNJhAVALvDfwKxCX6VdyNpthAMA7cmra+s0/weZsfQLyU2TtnsIg0uoq0\n"
"L4sTpL6Q7Fr4UpOJrezNx/kuHHxBBKhJtlz4Tcaw/OKu/h2g5jjHFT9yN86KUxSY\n"
"PDH47kk=\n"
"-----END CERTIFICATE-----\n";
// You can use x.509 client certificates if you want
const char *test_client_key =
"-----BEGIN RSA PRIVATE KEY-----\n"
"MIIEogIBAAKCAQEAllaf/na5h3yDr2zoYsYGGqt/d93/AAUTculGTXdGGbRwyHue\n"
"b0BaMeX+ht9siZ82iuaZ/5mJ/kq8WVwlrkegOAvU7SQDoALPM7VLMLSMbnn2Wqog\n"
"WE48TkWU0WddtTFHVDGLX8zMC1TQ1VKyVzp2QtCW9RPJNun9CVJSoZ34uM5hBL1f\n"
"7MY7t/QsDYi14UtULDsSnVz+tDLiPrBkZOPEVhopCH1gvljcDTcICfawyK5nlCKc\n"
"AnUWTHEUzf89WCJkPNk1W3LhscGKfx2bV8XVv+izg2zMLec5aYM/LrJg6HpJzgQJ\n"
"IKBt1tWQkxRvO7LO3znSp8A9DXotvr0MkIqcjQIDAQABAoIBAEMAaF3oW9deTvIn\n"
"/4nF54KLXEv3zGYd3QUhogt0VPGv0XQIZBwA+jGy5zUE7kKHiq9tBsU7kJycgkTx\n"
"JHn/whA4dbUaj+MIXYAWFGSoks3J3Vma6L9yXr4jlKefAcx3IesMCamwhF+odUod\n"
"iQ4HKB2vCRhAsTSgI/27isgst2TlJsGMf7ED2N1jae8ZyOITi2g0F1edRYBwgSHq\n"
"MZvccZh/IpuTOPEVxuITYyQT9WF0TCz7cK4wCP5dACQQB6Or8l2xiUf9dx3I7kwR\n"
"7wvivI+jAoxR/peOXx2o0bHPcqh41rbhbE00XOcIReGoyLsRDvicw3hgFe6UxcEm\n"
"PlpFzaECgYEAyBPpzK3x0iXj66iO6erXzciN5cXF8IZhC7xcCgGOpnjgrMV3FUNv\n"
"L0Qu8zUlTJHfWpITCZawPpbNMaNShykLU6NqxUPXGtaH/xVUZm9VbkRwBQoQKg+w\n"
"x2+hAWTGu4rWtSaWMHJuwI0SYyopvJtBgDO8PkmzDG24RQuRVBSE+ycCgYEAwFu6\n"
"QHVHvVm4ri1FCIK313uXTWoYhKDCm8ygDKT608bHzBoqOcXPT5mcr3IZmZitsg3Y\n"
"DyVvPGmmbLp8FmxXcz2c71e1Bupeq9V8HrMiSgMVPEIRuNKVC7WE/Ymuvpvfd+h/\n"
"RyDCu2wTI4GcJRhmAB+SpjPPOH0qaqV2eHZgSysCgYAO5eyy4QDwtQGTuqlpoaMQ\n"
"H67xPRjQIDF5vjzcQeFtY/LW6p1DaBIPYvRcB8kPOo13IQlp3V6iSnhdCdxLVDMT\n"
"t0dsCPErfm4CAISYXBHwdAgjV+x8NU7kittiTy69KEl0k7r7QIoerGKCH9GbybPG\n"
"6BNMUBCVDFZ8TbA0opKEYQKBgEl0/fxNjTbXA3qoWPt2B8SnMtFiWbiUN50NmHUb\n"
"r5meCIB94XAshQ2NyNMLDJGmR3Z+aOrnzcHRSresw2RAvWiJt9uCr+PTLpIKNZr3\n"
"p3mCEeLwDBp7eGV/TSkRIgUyOzVsOOatsQ+nputhPILB/XnAlN0ZXeHhkoglZcd8\n"
"1Sr/AoGAU7nlyAMQNd/tckwPTnM++0ewrFvwrfpS7f2dhcYbIhfqQ3I03Gwzjkkg\n"
"G85uzTg/8iO4oxPRjqPvc7JaoDDmGY/efQvjR+FdwDOuy+XZPImZIgGjl0yvAMFU\n"
"6azU+OxtwV+Yyfad4rGxaXZsqOIs18to94t2kjI0t8ur/4Q7C5w=\n"
"-----END RSA PRIVATE KEY-----\n"; // to verify the client
const char *test_client_cert =
"-----BEGIN CERTIFICATE-----\n"
"MIIDnjCCAoYCFBRQlTP3aMzr8YtFlYoaVtrPIN6xMA0GCSqGSIb3DQEBCwUAMIGH\n"
"MQswCQYDVQQGEwJWTjEQMA4GA1UECAwHdmlldG5hbTEQMA4GA1UEBwwHdmlldG5h\n"
"bTEOMAwGA1UECgwFcGVjb20xDTALBgNVBAsMBHRlc3QxDTALBgNVBAMMBG1xdHQx\n"
"JjAkBgkqhkiG9w0BCQEWF2NwdHByaWNlMTIzQG91dGxvb2suY29tMB4XDTIyMTEw\n"
"MzA4MTMzMVoXDTIzMDIxMTA4MTMzMVowgY4xCzAJBgNVBAYTAlZOMRAwDgYDVQQI\n"
"DAd2aWV0bmFtMRAwDgYDVQQHDAd2aWV0bmFtMQ4wDAYDVQQKDAVwZWNvbTENMAsG\n"
"A1UECwwEdGVzdDETMBEGA1UEAwwKbXF0dGNsaWVudDEnMCUGCSqGSIb3DQEJARYY\n"
"Y3B0cHJpY2VAMTIzQG91dGxvb2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A\n"
"MIIBCgKCAQEAllaf/na5h3yDr2zoYsYGGqt/d93/AAUTculGTXdGGbRwyHueb0Ba\n"
"MeX+ht9siZ82iuaZ/5mJ/kq8WVwlrkegOAvU7SQDoALPM7VLMLSMbnn2WqogWE48\n"
"TkWU0WddtTFHVDGLX8zMC1TQ1VKyVzp2QtCW9RPJNun9CVJSoZ34uM5hBL1f7MY7\n"
"t/QsDYi14UtULDsSnVz+tDLiPrBkZOPEVhopCH1gvljcDTcICfawyK5nlCKcAnUW\n"
"THEUzf89WCJkPNk1W3LhscGKfx2bV8XVv+izg2zMLec5aYM/LrJg6HpJzgQJIKBt\n"
"1tWQkxRvO7LO3znSp8A9DXotvr0MkIqcjQIDAQABMA0GCSqGSIb3DQEBCwUAA4IB\n"
"AQCF33dWLyL/QJKDBNtKc6WwmOn97u74jkIYdgRHgQwNvrmLHRgZPb6Bhzy5KAIY\n"
"qJcPA6Cn/m4utUWjAXRPj9zDT5xyeC843R22KQASjmPBnEyfDZuXmUPjjNJUSUx6\n"
"JGk/bwPQDLT2ID+vl3OInm4ypgwbGaqlhn41m0F2smanuZUFgEmN5+tJpkwK/tVP\n"
"IYHJ5HPnFqDFs84Fp12HU2QcqbOUEZ/d77Yw/dfb20cvgW2xkHKEAhz7d9EpD4ov\n"
"S5ZnelKxvqlVzI2v2I6MJkRdeP2IfYofNfRo2s7S5u+h/2SQu1MbbarS/jd32Ldz\n"
"14EVvDj+sCF2g7skdJ3kYCPI\n"
"-----END CERTIFICATE-----\n"; // to verify the client
Server config:
listen:0.0.0.0:4222
jetstream:{
max_memory_store: 1073741824
max_file_store: 1073741824
}
mqtt {
# Specify a host and port to listen for websocket connections
#
listen: "0.0.0.0:8883"
# It can also be configured with individual parameters,
# namely host and port.
#
# host: "hostname"
# port: 1883
# TLS configuration.
tls {
cert_file: /etc/tls/mqtt/broker/broker.crt
key_file: /etc/tls/mqtt/broker/broker.key
ca_file: /etc/tls/mqtt/ca/ca.crt
verify: true
timeout: 2.0
# verify_and_map: true
}
# no_auth_user: "my_username_for_apps_not_providing_credentials"
# authorization {
# # username: "my_user_name"
# # password: "my_password"
# # token: "my_token"
# # timeout: 2.0
# }
ack_wait: "1m"
max_ack_pending: 100
}
tls:{
cert_file: /etc/tls/natsio/server-cert.pem
key_file: /etc/tls/natsio/server-key.pem
ca_file: /etc/tls/natsio/ca-cert.pem
}
http_port: 8222
# system_account: AAOQAS43OSVDMF3ERYSNL3GMGZRD7GILDGDET6R52NFZKEWJOTTVNYZ4
# resolver: {
# type: full
# dir: './jwt'
# allow_delete: false
# interval: "2m"
# limit: 1000
# }
Logs from NATS server:
test-nats-dev-1 | [1] 2022/11/03 10:29:32.794114 [ERR] 192.168.1.14:57479 - mid:699 - TLS handshake error: remote error: tls: bad certificate
test-nats-dev-1 | [1] 2022/11/03 10:29:37.989099 [ERR] 192.168.1.14:57480 - mid:700 - TLS handshake error: remote error: tls: bad certificate
ESP32 logs:
Attempting MQTT connection...[2959556][E][ssl_client.cpp:37] _handle_error(): [start_ssl_client():276]: (-9984) X509 - Certificate verification failed, e.g. CRL, CA or signature check failed
[2959559][E][WiFiClientSecure.cpp:135] connect(): start_ssl_client: -9984
failed, rc=-2 try again in 5 seconds
Attempting MQTT connection...[2964762][E][ssl_client.cpp:37] _handle_error(): [start_ssl_client():276]: (-9984) X509 - Certificate verification failed, e.g. CRL, CA or signature check failed
[2964765][E][WiFiClientSecure.cpp:135] connect(): start_ssl_client: -9984
failed, rc=-2 try again in 5 seconds
Attempting MQTT connection...[2976298][E][ssl_client.cpp:37] _handle_error(): [start_ssl_client():276]: (-9984) X509 - Certificate verification failed, e.g. CRL, CA or signature check failed
[2976301][E][WiFiClientSecure.cpp:135] connect(): start_ssl_client: -9984
failed, rc=-2 try again in 5 seconds

I found the problem is my cert is using domain for certification and I using IP for connection. That is make it not working.
After change to using domain in connection it works normally.
Domain TLS: https://docs.cpanel.net/knowledge-base/general-systems-administration/what-is-domain-tls/
IP TLS: Is it possible to have SSL certificate for IP address, not domain name?

Related

Message is being sent with "send_message" in ejabberd using postman but not received by client

I have configured and install ejabberd on the ubuntu 22.04 and I have successfully configured and create one user with administrator right and as well as create some users into it.
I am using Version
OS - ubuntu 22.04 LTS
ejabberd 22.10
And also configured ejabberd API by mod_http_api and then I test APIs with POSTMAN, almost every (link) "API reference" working fine with it except send_message.
Here is my ejabberd.yml configuration:-
hosts:
- B660M-D2H-DDR4
- localhost
- XX.XXX.37.XX
loglevel: info
ca_file: /opt/ejabberd/conf/cacert.pem
certfiles:
- /opt/ejabberd/conf/server.pem
## If you already have certificates, list them here
# certfiles:
# - /etc/letsencrypt/live/domain.tld/fullchain.pem
# - /etc/letsencrypt/live/domain.tld/privkey.pem
listen:
-
port: 5222
ip: "::"
module: ejabberd_c2s
max_stanza_size: 262144
shaper: c2s_shaper
access: c2s
starttls_required: true
-
port: 5223
ip: "::"
tls: true
module: ejabberd_c2s
max_stanza_size: 262144
shaper: c2s_shaper
access: c2s
starttls_required: true
-
port: 5269
ip: "::"
module: ejabberd_s2s_in
max_stanza_size: 524288
-
port: 5443
ip: "::"
module: ejabberd_http
tls: true
request_handlers:
/admin: ejabberd_web_admin
/api: mod_http_api
/bosh: mod_bosh
/captcha: ejabberd_captcha
/upload: mod_http_upload
/ws: ejabberd_http_ws
-
port: 5280
ip: "::"
module: ejabberd_http
request_handlers:
/admin: ejabberd_web_admin
/.well-known/acme-challenge: ejabberd_acme
/api: mod_http_api
-
port: 3478
ip: "::"
transport: udp
module: ejabberd_stun
use_turn: true
## The server's public IPv4 address:
# turn_ipv4_address: "203.0.113.3"
## The server's public IPv6 address:
# turn_ipv6_address: "2001:db8::3"
-
port: 1883
ip: "::"
module: mod_mqtt
backlog: 1000
s2s_use_starttls: optional
acl:
admin:
user: "admin#localhost"
local:
user_regexp: ""
loopback:
ip:
- 127.0.0.0/8
- ::1/128
access_rules:
local:
allow: local
allow: XX.XXX.37.XX
c2s:
deny: blocked
allow: all
announce:
allow: admin
configure:
allow: admin
muc_create:
allow: local
pubsub_createnode:
allow: local
trusted_network:
allow: loopback
api_permissions:
"console commands":
from:
- ejabberd_ctl
who: all
what: "*"
"admin access":
who:
access:
allow:
- acl: admin
oauth:
scope: "ejabberd:admin"
access:
allow:
- acl: admin
what:
- "*"
- "!stop"
- "!start"
"public commands":
who:
ip: 127.0.0.1/8
what:
- status
- connected_users_number
shaper:
normal:
rate: 3000
burst_size: 20000
fast: 100000
shaper_rules:
max_user_sessions: 10
max_user_offline_messages:
5000: admin
100: all
c2s_shaper:
none: admin
normal: all
s2s_shaper: fast
modules:
mod_adhoc: {}
mod_admin_extra: {}
mod_announce:
access: announce
mod_avatar: {}
mod_blocking: {}
mod_bosh: {}
mod_caps: {}
mod_carboncopy: {}
mod_client_state: {}
mod_configure: {}
mod_disco: {}
mod_fail2ban: {}
mod_http_api: {}
mod_http_upload:
put_url: https://#HOST#:5443/upload
custom_headers:
"Access-Control-Allow-Origin": "https://#HOST#"
"Access-Control-Allow-Methods": "GET,HEAD,PUT,OPTIONS"
"Access-Control-Allow-Headers": "Content-Type"
mod_last: {}
mod_mam:
## Mnesia is limited to 2GB, better to use an SQL backend
## For small servers SQLite is a good fit and is very easy
## to configure. Uncomment this when you have SQL configured:
## db_type: sql
assume_mam_usage: true
default: always
mod_mqtt: {}
mod_muc:
access:
- allow
access_admin:
- allow: admin
access_create: muc_create
access_persistent: muc_create
access_mam:
- allow
default_room_options:
mam: true
mod_muc_admin: {}
mod_offline:
access_max_user_messages: max_user_offline_messages
mod_ping: {}
mod_privacy: {}
mod_private: {}
mod_proxy65:
access: local
max_connections: 5
mod_pubsub:
access_createnode: pubsub_createnode
plugins:
- flat
- pep
force_node_config:
## Avoid buggy clients to make their bookmarks public
storage:bookmarks:
access_model: whitelist
mod_push: {}
mod_push_keepalive: {}
mod_register:
## Only accept registration requests from the "trusted"
## network (see access_rules section above).
## Think twice before enabling registration from any
## address. See the Jabber SPAM Manifesto for details:
## https://github.com/ge0rg/jabber-spam-fighting-manifesto
ip_access: trusted_network
mod_roster:
versioning: true
mod_s2s_dialback: {}
mod_shared_roster: {}
mod_stream_mgmt:
resend_on_timeout: if_offline
mod_stun_disco: {}
mod_vcard: {}
mod_vcard_xupdate: {}
mod_version:
show_os: false
I have two observation with messages (send_message):
client to client (PSI)
postman to Client
In first observation I have success to exchange messages between users on psi(PSI) but when we try to send message with postman using "mod_http_api" API to the client, I am getting result 200 ok, but Message is not being delivered. And it is not showing anywhere (logs).
Am I missing something that is important for receiving a message using ejabberd's REST API with postman?
What a strange problem, I cannot reproduce it. You didn't show your command query, and didn't mention what exact client and configuration you are using.
Summary: Check if the command works correctly when using the ejabberdctl command line tool, and use "normal" message type, and send to bare JID, and use another client for example Gajim (just for debugging the problem).
Details:
I installed ejabberd 22.10 from source code, copied your configuration, disabled cert and tls options, started ejabberd, registered account, logged in it and executed this command:
$ ejabberdctl send_message headline uuu#localhost user1#localhost Restart aaa
The client that was logged in user1#localhost received the stanza, and displayed the headline message:
<message to='user1#localhost'
from='uuu#localhost'
type='headline'
id='18154938236359942834'>
<body>aaa</body>
<subject>Restart</subject>
</message>
Please note: in XMPP, "headline" messages are not stored in the offline storage: they are only received by online sessions with positive priority. Maybe you are sending "headline" messages to sessions that are offline, or online with negative priority, or online with no initial presence?
It's preferable to send a "normal" message, which are stored offline:
ejabberdctl send_message normal uuu#localhost user1#localhost ThisisNormal bbb
Also, make sure your client is logged in with positive priority (this is the standard).

How can I set [output_adapter.email] with Aruba address in wso2 Identity Server v. 5.11.0?

I'm trying to set an email sender (for example recovery password). I already set with a Gmail and Outlook address mail and it's work!
Now i nedd to configure an Aruba hostmail.
this is my deployment.toml configuration module
[output_adapter.email]
from_address= "****#aruba.it"
username= "*****#****.it"
password= "******"
hostname= "smtps.aruba.it"
port= 465
enable_start_tls= true
enable_authentication= true
signature = "****"
[output_adapter.email.custom_properties]
"mail.smtp.ssl.protocols"="TLSv1.2"
"mail.transport.protocol"="smtps"
Logs return
ERROR {org.wso2.carbon.event.output.adapter.email.EmailEventAdapter} - Event dropped at Output Adapter 'EmailPublisher' for tenant id '-1234', Error in message format, Could not connect to SMTP host: smtps.aruba.it, port: 465, response: -1 javax.mail.MessagingException: Could not connect to SMTP host: smtps.aruba.it, port: 465, response: -1
I tried with smpts and smpt (it should be the same port 465).
Can you tell me if it's not supported or something?
THanks, i really need help :(
I fixed it by adding these properties in deployment.toml file below this modules:
[output_adapter.email]
from_address= "***#aruba.it"
username= "****"
password= "****!"
hostname= "smtps.aruba.it"
port= 465
enable_start_tls= true
enable_authentication= true
signature = "WSO2"
[output_adapter.email.custom_properties]
"mail.smtp.ssl.protocols"="TLSv1.2"
"mail.smtp.debug"="true"
"mail.smtp.socketFactory.port"="465"
"mail.smtp.socketFactory.class"="javax.net.ssl.SSLSocketFactory"
"mail.smtp.socketFactory.fallback"="false"

Amazon root certificate pinning in Flutter, Dart

I'm using AWS CA to generate an SSL certificate for ElasticBeanstalk that I'm using in my Flutter app.
Based on the bets practices, I'm trying to pin HTTP client the Root certificate from Amazon Trusted Services
I face 2 issues with the Flutter HTTP client:
Whenever I try to load the certificate it crashes:
[VERBOSE-2:ui_dart_state.cc(209)] Unhandled Exception: TlsException: Failure trusting builtin roots (OS Error: BAD_PKCS12_DATA(pkcs8_x509.c:657), errno = 0)
This is the certificate I use (one of five, I add them all):
final _awsRoot1 = _decodePEM("""-----BEGIN CERTIFICATE-----
MIIDQTCCAimgAwIBAgITBmyfz5m/jAo54vB4ikPmljZbyjANBgkqhkiG9w0BAQsF
ADA5MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRkwFwYDVQQDExBBbWF6
b24gUm9vdCBDQSAxMB4XDTE1MDUyNjAwMDAwMFoXDTM4MDExNzAwMDAwMFowOTEL
MAkGA1UEBhMCVVMxDzANBgNVBAoTBkFtYXpvbjEZMBcGA1UEAxMQQW1hem9uIFJv
b3QgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALJ4gHHKeNXj
ca9HgFB0fW7Y14h29Jlo91ghYPl0hAEvrAIthtOgQ3pOsqTQNroBvo3bSMgHFzZM
9O6II8c+6zf1tRn4SWiw3te5djgdYZ6k/oI2peVKVuRF4fn9tBb6dNqcmzU5L/qw
IFAGbHrQgLKm+a/sRxmPUDgH3KKHOVj4utWp+UhnMJbulHheb4mjUcAwhmahRWa6
VOujw5H5SNz/0egwLX0tdHA114gk957EWW67c4cX8jJGKLhD+rcdqsq08p8kDi1L
93FcXmn/6pUCyziKrlA4b9v7LWIbxcceVOF34GfID5yHI9Y/QCB/IIDEgEw+OyQm
jgSubJrIqg0CAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMC
AYYwHQYDVR0OBBYEFIQYzIU07LwMlJQuCFmcx7IQTgoIMA0GCSqGSIb3DQEBCwUA
A4IBAQCY8jdaQZChGsV2USggNiMOruYou6r4lK5IpDB/G/wkjUu0yKGX9rbxenDI
U5PMCCjjmCXPI6T53iHTfIUJrU6adTrCC2qJeHZERxhlbI1Bjjt/msv0tadQ1wUs
N+gDS63pYaACbvXy8MWy7Vu33PqUXHeeE6V/Uq2V8viTO96LXFvKWlJbYK8U90vv
o/ufQJVtMVT8QtPHRh8jrdkPSHCa2XV4cdFyQzR1bldZwgJcJmApzyMZFo6IQ6XU
5MsI+yMRQ+hDKXJioaldXgjUkK642M4UwtBV8ob2xJNDd2ZhwLnoQdeXeGADbkpy
rqXRfboQnoZsG4q5WTP468SQvvG5
-----END CERTIFICATE-----""");
And this is what I do to decode PEM :
Uint8List _decodePEM(pem) {
for (var s in _startsWith) {
if (pem.startsWith(s)) pem = pem.substring(s.length);
}
for (var s in _endsWith) {
if (pem.endsWith(s)) pem = pem.substring(0, pem.length - s.length);
}
pem = pem.replaceAll('\n', '');
pem = pem.replaceAll('\r', '');
return Uint8List.fromList(base64.decode(pem));
}
And add it via:
void certificatePinningPem(SecurityContext context) {
context.setTrustedCertificatesBytes(_awsRoot1);
context.setTrustedCertificatesBytes(_awsRoot2);
context.setTrustedCertificatesBytes(_awsRoot3);
context.setTrustedCertificatesBytes(_awsRoot4);
context.setTrustedCertificatesBytes(_awsRoot5);
}
I get the same exception when I read DER file :
final aws1 = await rootBundle.load('assets/cer/aws1.cer');
context.setTrustedCertificatesBytes(aws1.buffer.asUint8List());
PEM file from the connection is different
Despite that, when I use badCertificateCallback, pem file from the certificate doesn't match any of those five from repo So how to get Root certificate from connection?
httpClient.badCertificateCallback = (
X509Certificate certificate,
String host,
int port,
) {
print('Bad certificate: ${certificate.pem} for host $host:$port');
return false;
};
Any suggestion on how to properly do certificate pinning in Flutter with AWS Root certificates?
I found a few related threads but they don't really help, i.e. https://github.com/flutter/flutter/issues/39190#issuecomment-693315205

Failed SSL handshake in Kafka Producer

I'm trying to set up a Kafka broker with SSL enabled communication.
I followed the guide as described in the Kafka documentation here under 7.2: https://kafka.apache.org/documentation/#security
When I'm trying to execute the command ./kafka-console-producer.sh --broker-list ec2-ip.eu-central-1.compute.amazonaws.com:9093 -topic test --producer.config ../config/producer.properties
I get:
ERROR [Producer clientId=console-producer] Connection to node -1 (ec2-ip.eu-central-1.compute.amazonaws.com/172.31.42.33:9093) failed authentication due to: SSL handshake failed (org.apache.kafka.clients.NetworkClient)
[2019-08-22 13:15:56,728] ERROR [Producer clientId=console-producer] Connection to node -1 (ec2-ip.eu-central-1.compute.amazonaws.com/172.31.42.33:9093) failed authentication due to: SSL handshake failed (org.apache.kafka.clients.NetworkClient)
Testing the SSl connection in general with
openssl s_client -debug -connect ec2-ip.eu-central-1.compute.amazonaws.com:9093 -tls1
results in
0020 - a0 41 45 81 42 b6 83 d3-2b 94 02 9f ac 42 73 42 .AE.B...+....BsB
---
Certificate chain
0 s:/C=Unknown/ST=Unknown/L=Unknown/O=Unknown/OU=Unknown/CN=Unknown
i:/C=Unknown/ST=Unknown/L=Unknown/O=Unknown/OU=Unknown/CN=Unknown
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDuTCCAqGgAwIBAgIEPsshdTANBgkqhkiG9w0BAQsFADBsMRAwDgYDVQQGEwdV
bmtub3duMRAwDgYDVQQIEwdVbmtub3duMRAwDgYDVQQHEwdVbmtub3duMRAwDgYD
VQQKEwdVbmtub3duMRAwDgYDVQQLEwdVbmtub3duMRAwDgYDVQQDEwdVbmtub3du
MB4XDTE5MDgyMjEyNTIwOFoXDTIwMDgyMTEyNTIwOFowbDEQMA4GA1UEBhMHVW5r
bm93bjEQMA4GA1UECBMHVW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4GA1UE
ChMHVW5rbm93bjEQMA4GA1UECxMHVW5rbm93bjEQMA4GA1UEAxMHVW5rbm93bjCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI5EKxmSDLQvW/ePu9mB3qdf
E4cG1ok1kI48S6yL4gchx2egIC6Zjr5gBhuek36mhKV82H1nVYfDzJVyxoyaTZ5q
ux8xq+ooNN/chKHy0ExpCZ2HHvrQiTPQit//dyA5zc5yOyRcJo/m2EhYfRMuLfFM
kx1mEg2cs6Qa/hd6jKjCSvbcKDfrOhf4rLagHzI+2GRQfF6LXxYBE3Ti7u6fkqog
o67CTrNR6IER1b4wGIeHga8eXiVhOuP4JiWdpF69i5py0RVfzsesP0W8RB2qElte
+7EwShaFO72Xa7MPiDz1rE4D5pohQ09AWGb/B0YIcI7qh9jyInbj4eWhhlnd1lsC
AwEAAaNjMGEwQAYDVR0RBDkwN4I1ZWMyLTM1LTE1OC0yMzItMTc2LmV1LWNlbnRy
YWwtMS5jb21wdXRlLmFtYXpvbmF3cy5jb20wHQYDVR0OBBYEFNGugrNUmFiVKVyU
Uiepd0OUme1wMA0GCSqGSIb3DQEBCwUAA4IBAQAToYYUsvQ6MlOQ+HHWnfax5L0u
M/IrExjcrSmnxAevnTem5+Hnz+AmlRHSF1/FfCWhi2XMSHBHXU52uhIt+kDLNhFh
D17Je0FydthW8roBsLZ+XsuHjBi8MXo41YAA19+cjW60/se3+kWxOHH1rEfV9ky/
K9kWufQPl3U3fbUzh0rWwriSDaPUTjHg/IeROhVe8gt/QeBfTU2KUqnln6K58PfC
kE2c2zCTQwpsfwi5gqvrdqWZc/A5qriv1l39zKU1icfTZzdeejcjtbCdFqajOqar
lMXwyl1bPuPiOHas7K9J9MSREQYql89gbN5V9gO//IHmM97eLt4npFSpu8Cp
-----END CERTIFICATE-----
subject=/C=Unknown/ST=Unknown/L=Unknown/O=Unknown/OU=Unknown/CN=Unknown
issuer=/C=Unknown/ST=Unknown/L=Unknown/O=Unknown/OU=Unknown/CN=Unknown
---
No client certificate CA names sent
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1451 bytes and written 236 bytes
Verification error: self signed certificate
---
New, TLSv1.0, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: 5D5E9882C4E8DD80427108B85C7649F0EC1AA87B9DAA0EA1FCE8C7063C83A61B
Session-ID-ctx:
Master-Key: 861677EDA9E19E3D8926889A9B0DE299593C7FCD49DB8A55EBF4D222800169E16CDB74DCE0EC392A3B491268FCCF5F07
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1566480514
Timeout : 7200 (sec)
Verify return code: 18 (self signed certificate)
Extended master secret: yes
---
which looks ok to me.
Configuration of the Broker:
listeners=SSL://ec2-ip.eu-central-1.compute.amazonaws.com:9093,PLAINTEXT://ec2-ip.eu-central-1.compute.amazonaws.com:9092
group.initial.rebalance.delay.ms=0
advertised.listeners=PLAINTEXT://ec2-ip.eu-central-1.compute.amazonaws.com:9092,SSL://ec2-ip.eu-central-1.compute.amazonaws.com:9093
ssl.endpoint.identification.algorithm=SSL
ssl.keystore.location=/kafka/kafka_2.12-2.2.0/config/certs/server.keystore.jks
ssl.keystore.password=Welcome01
ssl.key.password=Welcome01
ssl.truststore.location=/kafka/kafka_2.12-2.2.0/config/certs/server.truststore.jks
ssl.truststore.password=Welcome01
ssl.enabled.protocols=TLSv1.2,TLSv1.1,TLSv1
ssl.keystore.type=JKS
ssl.truststore.type=JKS
Configuration of the Producer:
bootstrap.servers=localhost:9092
security.protocol=SSL
ssl.truststore.location=/kafka/kafka_2.12-2.2.0/config/certs/client.truststore.jks
ssl.truststore.password=Welcome01
logging.level.org.apache.kafka: DEBUG
log4j.rootLogger=DEBUG
Do you see some misconfiguration? How can I proceed to investigate further to get down to the issue?
Thanks to mazaneiche I was able to get the error that leads to the failed handshake:
kafka-producer-network-thread | console-producer, fatal error: 46: General SSLEngine problem
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
%% Invalidated: [Session-3, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384]
kafka-producer-network-thread | console-producer, SEND TLSv1.2 ALERT: fatal, description = certificate_unknown
Why does this error occur? How can it be fixed?
Apparently not the issue here but I have been struggling with the same error for a while and in my case the kafka-console-producer.sh was failing with the similar errors:
$ kafka-console-producer.sh --broker-list 192.168.1.173:9093 --topic kafka-security-topic --producer.config ~/ssl/client-ssl-auth.properties
org.apache.kafka.common.errors.SslAuthenticationException: SSL handshake failed
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
checking with debug
$ export KAFKA_OPTS="-Djavax.net.debug=ssl"
kafka-producer-network-thread | console-producer, fatal error: 46: General SSLEngine problem
java.security.cert.CertificateException: No subject alternative names present
%% Invalidated: [Session-1, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384]
kafka-producer-network-thread | console-producer, SEND TLSv1.2 ALERT: fatal, description = certificate_unknown
[2021-07-13 16:21:53,909] ERROR [Producer clientId=console-producer] Connection to node -1 (/192.168.1.173:9093) failed authentication due to: SSL handshake failed (org.apache.kafka.clients.NetworkClient)
In my case turned out the reason is using IP instead of hostname when specifying broker-list parameter.
That worked:
$ kafka-console-producer.sh --broker-list red03:9093 --topic kafka-security-topic --producer.config ~/ssl/client-ssl-auth.properties

Poco + OpenSSL + CA PEM : "Unacceptable certificate" error for 1 out of 2 identical sites

I am trying to do a SSL handshake with www1.filemail.com. I am using cURL's cacert.pem, but I am getting this error:
Unacceptable certificate from 188.138.81.30: application verification failure
Making the handshake against any other HTTPS website works - including www2.filemail.com. www1 and www2 should be identically configured - and they both work fine in all browsers. They also test fine here (identical certificates and intermediary certificates are sent out for both sites):
SSL Labs www1.filemail.com
SSL Labs www2.filemail.com
Why am I getting this problem with www1 using OpenSSL and the cacert.pem file?
There has to be a difference in the certificate setup of www1 and www2. I have tested with a myriad of tools (openssl, ssllabs etc.) to try to pinpoint the difference - but I always get the exact same results for both sites (except when running my code)
What am I missing here? What's the difference between the sites?
(It should be noted that we are using a relatively cheap wildcard certificate provided by RapidSSL - so I'm guessing it has something to do with intermediate or cross-root certificates - but everything seems to be in order when testing with the tools mentioned above.)
Code:
Poco::SharedPtr<Poco::Net::InvalidCertificateHandler> pCert = new Poco::Net::ConsoleCertificateHandler(false);
Poco::Net::Context::Ptr pContext = new Poco::Net::Context(Poco::Net::Context::CLIENT_USE, "", "", "C:\\cacert.pem", Poco::Net::Context::VERIFY_RELAXED, 9, false, "ALL:!ADH:!LOW:!EXP:!MD5:#STRENGTH");
Poco::Net::SSLManager::instance().initializeClient(0, pCert, pContext);
URI uri("https://www1.filemail.com");
Poco::Net::SecureStreamSocket ss(Poco::Net::SocketAddress(uri.getHost().c_str(), uri.getPort()));
ss.completeHandshake();
www1 and www2 should be identically configured - and they both work fine in all browsers...
Here are the certificates. A diff shows they are the same end-entity (server) certificate:
$ diff www1.txt www2.txt
$
Each server is could be a sending a different chain. Use openssl s_client with openssl x509 and -showcerts to get the chain.
www1
$ openssl s_client -connect www1.filemail.com:443 -tls1 -servername www1.filemail.com | openssl x509 -text -noout > www1.txt
depth=1 C = US, O = GeoTrust Inc., CN = RapidSSL SHA256 CA - G3
verify error:num=20:unable to get local issuer certificate
^C
riemann:~$ cat www1.txt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 15955 (0x3e53)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = GeoTrust Inc., CN = RapidSSL SHA256 CA - G3
Validity
Not Before: Oct 14 20:14:57 2014 GMT
Not After : Aug 4 13:09:28 2018 GMT
Subject: OU = GT83551982, OU = See www.rapidssl.com/resources/cps (c)14, OU = Domain Control Validated - RapidSSL(R), CN = *.filemail.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c5:38:89:72:40:74:77:e2:76:f0:20:ae:d9:91:
26:ac:42:85:03:86:ff:2f:a1:94:b7:f3:86:4c:f7:
ce:63:46:47:e6:03:73:95:01:07:0b:e0:60:9a:93:
c3:b4:14:bc:4e:16:f2:50:12:89:11:42:f5:58:51:
74:15:81:d0:ce:6e:e2:85:e8:d2:3a:38:48:a3:02:
80:e0:a1:fa:ea:8f:ca:ee:bc:00:b3:b2:64:7f:9c:
da:ca:e8:3f:a7:48:af:5c:ed:8e:2f:27:95:19:52:
85:d1:15:9b:f5:4d:b7:21:44:89:05:6f:06:92:7b:
ab:9e:10:63:be:7e:ce:3b:58:10:68:ae:7a:52:6e:
e5:62:bf:ff:56:33:06:51:e5:61:a0:bd:6b:3c:c9:
f3:55:54:02:16:f2:56:27:81:be:83:82:53:25:1e:
c4:1c:1d:65:da:9f:2c:f7:97:49:3c:e1:03:35:1c:
da:c3:02:6d:93:1a:4a:89:53:4c:f5:3e:e7:f9:b9:
c0:10:e0:80:77:3a:d9:5d:ed:b1:46:9e:92:7e:86:
46:d7:be:fe:af:5a:af:02:b4:1b:d2:2b:08:1d:bc:
b5:93:8c:48:45:27:ba:26:69:a9:a8:9f:98:d3:de:
2d:f5:70:f5:39:6a:30:3b:8c:01:6c:85:19:a2:a6:
9a:65
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:C3:9C:F3:FC:D3:46:08:34:BB:CE:46:7F:A0:7C:5B:F3:E2:08:CB:59
Authority Information Access:
OCSP - URI:http://gv.symcd.com
CA Issuers - URI:http://gv.symcb.com/gv.crt
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Subject Alternative Name:
DNS:*.filemail.com, DNS:filemail.com
X509v3 CRL Distribution Points:
Full Name:
URI:http://gv.symcb.com/gv.crl
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Certificate Policies:
Policy: 2.16.840.1.113733.1.7.54
CPS: https://www.rapidssl.com/legal
Signature Algorithm: sha256WithRSAEncryption
77:7e:54:47:93:6c:b0:4e:9c:dc:01:47:1f:76:54:9d:f2:42:
94:c1:94:f8:7b:b4:68:82:fe:6d:66:45:68:e1:bd:df:ba:6d:
15:a1:6c:b0:79:9e:d7:99:d9:11:7e:84:e9:f1:63:7c:92:25:
c3:fe:cc:02:1a:61:b9:a3:29:59:18:c2:f1:d2:d7:84:dc:8d:
28:2e:b5:6e:91:d9:68:65:37:5a:b9:b3:d5:f4:d1:1f:b2:ec:
2b:0f:e1:50:30:72:f7:04:70:68:26:b0:61:47:44:49:d0:62:
31:81:53:fa:cc:3a:7b:a1:3b:74:da:c2:3b:7b:5d:9c:23:de:
69:92:51:fc:ff:8d:7a:ea:fd:b2:68:5f:38:3d:22:f6:a6:4a:
d7:a0:88:97:06:54:fd:ba:dc:b9:3a:69:25:89:99:0e:81:82:
c8:63:5c:87:98:bf:70:08:0a:89:20:a1:17:63:31:26:7b:af:
b3:83:f3:9c:b6:7e:64:52:08:bf:a3:74:d5:0c:26:f6:25:7c:
b9:cb:27:57:88:7f:af:1c:b5:99:08:4a:fd:c2:b4:ec:7a:40:
ea:80:ac:e8:88:84:33:53:ab:90:af:bc:bc:ea:6f:88:fe:a8:
f9:c7:63:a3:74:2c:0b:37:5c:90:39:ad:85:82:6a:e9:ea:a7:
e1:55:c2:dd
www2
$ openssl s_client -connect www2.filemail.com:443 -tls1 -servername www2.filemail.com | openssl x509 -text -noout > www2.txt
depth=1 C = US, O = GeoTrust Inc., CN = RapidSSL SHA256 CA - G3
verify error:num=20:unable to get local issuer certificate
^C
riemann:~$ cat www2.txt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 15955 (0x3e53)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = GeoTrust Inc., CN = RapidSSL SHA256 CA - G3
Validity
Not Before: Oct 14 20:14:57 2014 GMT
Not After : Aug 4 13:09:28 2018 GMT
Subject: OU = GT83551982, OU = See www.rapidssl.com/resources/cps (c)14, OU = Domain Control Validated - RapidSSL(R), CN = *.filemail.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c5:38:89:72:40:74:77:e2:76:f0:20:ae:d9:91:
26:ac:42:85:03:86:ff:2f:a1:94:b7:f3:86:4c:f7:
ce:63:46:47:e6:03:73:95:01:07:0b:e0:60:9a:93:
c3:b4:14:bc:4e:16:f2:50:12:89:11:42:f5:58:51:
74:15:81:d0:ce:6e:e2:85:e8:d2:3a:38:48:a3:02:
80:e0:a1:fa:ea:8f:ca:ee:bc:00:b3:b2:64:7f:9c:
da:ca:e8:3f:a7:48:af:5c:ed:8e:2f:27:95:19:52:
85:d1:15:9b:f5:4d:b7:21:44:89:05:6f:06:92:7b:
ab:9e:10:63:be:7e:ce:3b:58:10:68:ae:7a:52:6e:
e5:62:bf:ff:56:33:06:51:e5:61:a0:bd:6b:3c:c9:
f3:55:54:02:16:f2:56:27:81:be:83:82:53:25:1e:
c4:1c:1d:65:da:9f:2c:f7:97:49:3c:e1:03:35:1c:
da:c3:02:6d:93:1a:4a:89:53:4c:f5:3e:e7:f9:b9:
c0:10:e0:80:77:3a:d9:5d:ed:b1:46:9e:92:7e:86:
46:d7:be:fe:af:5a:af:02:b4:1b:d2:2b:08:1d:bc:
b5:93:8c:48:45:27:ba:26:69:a9:a8:9f:98:d3:de:
2d:f5:70:f5:39:6a:30:3b:8c:01:6c:85:19:a2:a6:
9a:65
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:C3:9C:F3:FC:D3:46:08:34:BB:CE:46:7F:A0:7C:5B:F3:E2:08:CB:59
Authority Information Access:
OCSP - URI:http://gv.symcd.com
CA Issuers - URI:http://gv.symcb.com/gv.crt
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Subject Alternative Name:
DNS:*.filemail.com, DNS:filemail.com
X509v3 CRL Distribution Points:
Full Name:
URI:http://gv.symcb.com/gv.crl
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Certificate Policies:
Policy: 2.16.840.1.113733.1.7.54
CPS: https://www.rapidssl.com/legal
Signature Algorithm: sha256WithRSAEncryption
77:7e:54:47:93:6c:b0:4e:9c:dc:01:47:1f:76:54:9d:f2:42:
94:c1:94:f8:7b:b4:68:82:fe:6d:66:45:68:e1:bd:df:ba:6d:
15:a1:6c:b0:79:9e:d7:99:d9:11:7e:84:e9:f1:63:7c:92:25:
c3:fe:cc:02:1a:61:b9:a3:29:59:18:c2:f1:d2:d7:84:dc:8d:
28:2e:b5:6e:91:d9:68:65:37:5a:b9:b3:d5:f4:d1:1f:b2:ec:
2b:0f:e1:50:30:72:f7:04:70:68:26:b0:61:47:44:49:d0:62:
31:81:53:fa:cc:3a:7b:a1:3b:74:da:c2:3b:7b:5d:9c:23:de:
69:92:51:fc:ff:8d:7a:ea:fd:b2:68:5f:38:3d:22:f6:a6:4a:
d7:a0:88:97:06:54:fd:ba:dc:b9:3a:69:25:89:99:0e:81:82:
c8:63:5c:87:98:bf:70:08:0a:89:20:a1:17:63:31:26:7b:af:
b3:83:f3:9c:b6:7e:64:52:08:bf:a3:74:d5:0c:26:f6:25:7c:
b9:cb:27:57:88:7f:af:1c:b5:99:08:4a:fd:c2:b4:ec:7a:40:
ea:80:ac:e8:88:84:33:53:ab:90:af:bc:bc:ea:6f:88:fe:a8:
f9:c7:63:a3:74:2c:0b:37:5c:90:39:ad:85:82:6a:e9:ea:a7:
e1:55:c2:dd
I am trying to do a SSL handshake towards www1.filemail.com - but I am
getting this error:
Unacceptable certificate from 188.138.81.30: application verification failure
RapidSSL SHA256 CA - G3 is a CA; it issued the server's certificate. The server is called the subject. As you work up a chain, the former issuer becomes the current subject. At the top of the chain is the self signed root. At the root, the issuer==subject.
The RapidSSL G3 CA is either (1) self-signed, so its a root CA; or (2) signed by another CA higher in the chain, so its a subordinate CA (i.e., it has an issuer). In this case, the G3 CA is a subordinate and it has an issuer.
It sounds like one server is sending the complete chain needed to validate the server's certificate; and the other server is not. Servers are supposed to send the complete chain to avoid the "which directory" problem in PKI. The "complete chain" is every certificate except the self-signed root (but many send the root, too).
The client must trust the self-signed root a priori, and its why it should not be sent (otherwise, a bad guy can swap-in his own chain). Or, instead of using cacert.pem:
Poco::Net::Context::CLIENT_USE, "", "", "C:\\cacert.pem", ...
You can load RapidSSL SHA256 CA - G3 and use that as the root of the trust. You will avoid the other 300 or so CA's in cacert.pem that are not needed to validate the server chain. Its good security engineering.
You can fetch RapidSSL SHA256 CA - G3 from rapidSSL's site at Intermediate CA Certificate: RapidSSL with SHA-2 (under SHA-1 Root).
UPDATE using RapidSSL SHA256 CA - G3:
Here's the signer's certificate:
$ cat rapidssl.pem
-----BEGIN CERTIFICATE-----
MIIEJTCCAw2gAwIBAgIDAjp3MA0GCSqGSIb3DQEBCwUAMEIxCzAJBgNVBAYTAlVT
MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i
YWwgQ0EwHhcNMTQwODI5MjEzOTMyWhcNMjIwNTIwMjEzOTMyWjBHMQswCQYDVQQG
EwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEgMB4GA1UEAxMXUmFwaWRTU0wg
U0hBMjU2IENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCv
VJvZWF0eLFbG1eh/9H0WA//Qi1rkjqfdVC7UBMBdmJyNkA+8EGVf2prWRHzAn7Xp
SowLBkMEu/SW4ib2YQGRZjEiwzQ0Xz8/kS9EX9zHFLYDn4ZLDqP/oIACg8PTH2lS
1p1kD8mD5xvEcKyU58Okaiy9uJ5p2L4KjxZjWmhxgHsw3hUEv8zTvz5IBVV6s9cQ
DAP8m/0Ip4yM26eO8R5j3LMBL3+vV8M8SKeDaCGnL+enP/C1DPz1hNFTvA5yT2AM
QriYrRmIV9cE7Ie/fodOoyH5U/02mEiN1vi7SPIpyGTRzFRIU4uvt2UevykzKdkp
YEj4/5G8V1jlNS67abZZAgMBAAGjggEdMIIBGTAfBgNVHSMEGDAWgBTAephojYn7
qwVkDBF9qn1luMrMTjAdBgNVHQ4EFgQUw5zz/NNGCDS7zkZ/oHxb8+IIy1kwEgYD
VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAQYwNQYDVR0fBC4wLDAqoCig
JoYkaHR0cDovL2cuc3ltY2IuY29tL2NybHMvZ3RnbG9iYWwuY3JsMC4GCCsGAQUF
BwEBBCIwIDAeBggrBgEFBQcwAYYSaHR0cDovL2cuc3ltY2QuY29tMEwGA1UdIARF
MEMwQQYKYIZIAYb4RQEHNjAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3Lmdlb3Ry
dXN0LmNvbS9yZXNvdXJjZXMvY3BzMA0GCSqGSIb3DQEBCwUAA4IBAQCjWB7GQzKs
rC+TeLfqrlRARy1+eI1Q9vhmrNZPc9ZE768LzFvB9E+aj0l+YK/CJ8cW8fuTgZCp
fO9vfm5FlBaEvexJ8cQO9K8EWYOHDyw7l8NaEpt7BDV7o5UzCHuTcSJCs6nZb0+B
kvwHtnm8hEqddwnxxYny8LScVKoSew26T++TGezvfU5ho452nFnPjJSxhJf3GrkH
uLLGTxN5279PURt/aQ1RKsHWFf83UTRlUfQevjhq7A6rvz17OQV79PP7GqHQyH5O
ZI3NjGFVkP46yl0lD/gdo0p0Vk8aVUBwdSWmMy66S6VdU5oNMOGNX2Esr8zvsJmh
gP8L8mJMcCaY
-----END CERTIFICATE-----
Notice OpenSSL finished with Verify return code: 2 (unable to get issuer certificate). That's fine because you don't care about the issuer. You've rooted your trust at GeoTrust Inc., CN = RapidSSL SHA256 CA - G3, and RapidSSL SHA256 CA - G3 certified/signed the server's certificate.
$ openssl s_client -connect www1.filemail.com:443 -tls1 -servername www1.filemail.com -CAfile rapidssl.pem
CONNECTED(00000003)
depth=1 C = US, O = GeoTrust Inc., CN = RapidSSL SHA256 CA - G3
verify error:num=2:unable to get issuer certificate
issuer= C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
Server did acknowledge servername extension.
---
Certificate chain
0 s:/OU=GT83551982/OU=See www.rapidssl.com/resources/cps (c)14/OU=Domain Control Validated - RapidSSL(R)/CN=*.filemail.com
i:/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3
1 s:/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEsDCCA5igAwIBAgICPlMwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCVVMx
FjAUBgNVBAoTDUdlb1RydXN0IEluYy4xIDAeBgNVBAMTF1JhcGlkU1NMIFNIQTI1
NiBDQSAtIEczMB4XDTE0MTAxNDIwMTQ1N1oXDTE4MDgwNDEzMDkyOFowgZIxEzAR
BgNVBAsTCkdUODM1NTE5ODIxMTAvBgNVBAsTKFNlZSB3d3cucmFwaWRzc2wuY29t
L3Jlc291cmNlcy9jcHMgKGMpMTQxLzAtBgNVBAsTJkRvbWFpbiBDb250cm9sIFZh
bGlkYXRlZCAtIFJhcGlkU1NMKFIpMRcwFQYDVQQDDA4qLmZpbGVtYWlsLmNvbTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMU4iXJAdHfidvAgrtmRJqxC
hQOG/y+hlLfzhkz3zmNGR+YDc5UBBwvgYJqTw7QUvE4W8lASiRFC9VhRdBWB0M5u
4oXo0jo4SKMCgOCh+uqPyu68ALOyZH+c2sroP6dIr1ztji8nlRlShdEVm/VNtyFE
iQVvBpJ7q54QY75+zjtYEGiuelJu5WK//1YzBlHlYaC9azzJ81VUAhbyVieBvoOC
UyUexBwdZdqfLPeXSTzhAzUc2sMCbZMaSolTTPU+5/m5wBDggHc62V3tsUaekn6G
Rte+/q9arwK0G9IrCB28tZOMSEUnuiZpqaifmNPeLfVw9TlqMDuMAWyFGaKmmmUC
AwEAAaOCAVgwggFUMB8GA1UdIwQYMBaAFMOc8/zTRgg0u85Gf6B8W/PiCMtZMFcG
CCsGAQUFBwEBBEswSTAfBggrBgEFBQcwAYYTaHR0cDovL2d2LnN5bWNkLmNvbTAm
BggrBgEFBQcwAoYaaHR0cDovL2d2LnN5bWNiLmNvbS9ndi5jcnQwDgYDVR0PAQH/
BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAnBgNVHREEIDAe
gg4qLmZpbGVtYWlsLmNvbYIMZmlsZW1haWwuY29tMCsGA1UdHwQkMCIwIKAeoByG
Gmh0dHA6Ly9ndi5zeW1jYi5jb20vZ3YuY3JsMAwGA1UdEwEB/wQCMAAwRQYDVR0g
BD4wPDA6BgpghkgBhvhFAQc2MCwwKgYIKwYBBQUHAgEWHmh0dHBzOi8vd3d3LnJh
cGlkc3NsLmNvbS9sZWdhbDANBgkqhkiG9w0BAQsFAAOCAQEAd35UR5NssE6c3AFH
H3ZUnfJClMGU+Hu0aIL+bWZFaOG937ptFaFssHme15nZEX6E6fFjfJIlw/7MAhph
uaMpWRjC8dLXhNyNKC61bpHZaGU3Wrmz1fTRH7LsKw/hUDBy9wRwaCawYUdESdBi
MYFT+sw6e6E7dNrCO3tdnCPeaZJR/P+Neur9smhfOD0i9qZK16CIlwZU/brcuTpp
JYmZDoGCyGNch5i/cAgKiSChF2MxJnuvs4PznLZ+ZFIIv6N01Qwm9iV8ucsnV4h/
rxy1mQhK/cK07HpA6oCs6IiEM1OrkK+8vOpviP6o+cdjo3QsCzdckDmthYJq6eqn
4VXC3Q==
-----END CERTIFICATE-----
subject=/OU=GT83551982/OU=See www.rapidssl.com/resources/cps (c)14/OU=Domain Control Validated - RapidSSL(R)/CN=*.filemail.com
issuer=/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3
---
No client certificate CA names sent
Server Temp Key: ECDH, P-521, 521 bits
---
SSL handshake has read 2834 bytes and written 338 bytes
Verification error: unable to get issuer certificate
---
New, SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: 27390000AF3638FDEA75DDF52B9D937F290593304123134062F049306BBDE87F
Session-ID-ctx:
Master-Key: E8E2613F6267C705CA82EEE4C8A992880A2ABDA9E8D477A10C952764B1F4DD3D39244D3F0AD915B8FEB7E5FA1E8D55FD
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1473889933
Timeout : 7200 (sec)
Verify return code: 2 (unable to get issuer certificate)
Extended master secret: yes
----
Günter Obiltschnig helped me out via POCO#Github and got it working by replacing
Poco::Net::SecureStreamSocket ss(Poco::Net::SocketAddress(uri.getHost().c_str(), uri.getPort()));
with
Poco::Net::SecureStreamSocket ss(Poco::Net::SocketAddress(uri.getHost().c_str(), uri.getPort()), uri.getHost());
(including the host name in the constructor of SecureStreamSocket - it is used for certificate verification)
From the POCO documentation:
SecureStreamSocket(
const SocketAddress & address,
const std::string & hostName
);
//Creates a secure stream socket using the default client SSL context and connects it to the socket specified by address.
//The given host name is used for certificate verification <=======
I still do not know the exact difference in config between www1 and www2 are, would love if someone could enlighten me on this.