I try to connect a Shelly 1 PM smart power relay to a managed MQTT broker.
The firmware on the device is a custom-built Tasmota 8.3.1 from the dev branch with USE_MQTT_TLS enabled. The port is set correctly to 8883 for TLS and the broker service is running at mqtt.bosch-iot-hub.com
When the device boots up, I can see the log messages on the serial port as follows:
23:03:03 MQT: Connect failed to mqtt.bosch-iot-hub.com:8883, rc 4. Retry in 10 sec
23:03:14 MQT: Attempting connection...
23:03:14 MQT: TLS connection error: 0
Return Code 4 is, according to the Tasmota documentation (https://tasmota.github.io/docs/TLS/), the code for BR_ERR_BAD_VERSION
And this error constant seems to be from BearSSL and means "Incoming record version does not match the expected version." (according to http://sources.freebsd.org/HEAD/src/contrib/bearssl/tools/errors.c)
Using an online TLS testing tool and checking mqtt.bosch-iot-hub, it supports only TLS 1.2 (1.3, 1.1 and 1.0 being disabled as well as SSLv2 and SSLv3). BearSSL website states that it supports TLS 1.2
I tried setting the log level of Tasmota in my_user_config.h , but it does not log any more verbose or detailed information.
#define SERIAL_LOG_LEVEL LOG_LEVEL_DEBUG_MORE // [SerialLog] (LOG_LEVEL_NONE, LOG_LEVEL_ERROR, LOG_LEVEL_INFO, LOG_LEVEL_DEBUG, LOG_LEVEL_DEBUG_MORE)
What is the error message supposed to mean? Is it a TLS incompatibility of the BearSSL stack or on the service side?
How can I enable verbose logging on Tasmota to see detailed TLS handshake information?
Anything else I am missing?
I appreciate after 6 months the question may have been a little expired, however the error code is not the TLS one as you describe, but rather the return code for the MQTT connection, as described in
https://tasmota.github.io/docs/MQTT/#return-codes-rc
which means your error code corresponds to
4 MQTT_CONNECT_BAD_CREDENTIALS the username/password were rejected
Related
I am stuck at using SSL in IBM Websphere MQ (9.2).
I am building a client library for MQ and to get more familiar with MQ on the server side I have installed IBM MQ Developer edition and ran the supplied scripts to create a 'default' MQ server instance.
Created an client connection for the DEV.APP.SVRCONN server connection
Created a personal certificate by using the IBM Key management tool and named it ibmwebspheremq
Enabled SSL on the Queue Manager (QM1) and labelled it ibmwebspheremq
Updated the SSL configuration for the DEV.APP.SVRCONN channel and set the cipherspec property to TLS 1.2, 256-bit Secure Hash Algorithm, 128-bit AES encryption (TLS_RSA_WITH_AES_128_CBC_SHA256) and made SSL required.
Tested my settings with:
amqssslc -l ibmwebspheremq -k C:\ProgramData\IBM\MQ\qmgrs\QM1\ssl\key -c DEV.APP.SVRCONN -x 127.0.0.1 -s TLS_RSA_WITH_AES_128_CBC_SHA256 -m QM1
And that gave me:
Sample AMQSSSLC start
Connecting to queue manager QM1
Using the server connection channel DEV.APP.SVRCONN
on connection name 127.0.0.1.
Using SSL CipherSpec TLS_RSA_WITH_AES_128_CBC_SHA256
Using SSL key repository stem C:\ProgramData\IBM\MQ\qmgrs\QM1\ssl\key
Certificate Label: ibmwebspheremq
No OCSP configuration specified.
MQCONNX ended with reason code 2035
Error details (from log):
The active values of the channel were 'MCAUSER(app) CLNTUSER(Wilko)
SSLPEER(SERIALNUMBER=61:9B:A4:3E,CN=DESKTOP-ROH98N2,C=NL)
SSLCERTI(CN=DESKTOP-ROH98N2,C=NL) ADDRESS(DESKTOP-ROH98N2)'. The
MATCH(RUNCHECK) mode of the DISPLAY CHLAUTH MQSC command can be used to
identify the relevant CHLAUTH record.
ACTION:
Ensure that the application provides a valid user ID and password, or change
the queue manager connection authority (CONNAUTH) configuration to OPTIONAL to
allow client applications to connect which have not supplied a user ID and
password.
----- cmqxrmsa.c : 2086 -------------------------------------------------------
22/11/2021 15:51:37 - Process(15880.45) User(MUSR_MQADMIN) Program(amqrmppa.exe)
Host(DESKTOP-ROH98N2) Installation(Installation1)
VRMF(9.2.3.0) QMgr(QM1)
Time(2021-11-22T14:51:37.594Z)
CommentInsert1(DEV.APP.SVRCONN)
CommentInsert2(15880(1112))
CommentInsert3(127.0.0.1)
AMQ9999E: Channel 'DEV.APP.SVRCONN' to host '127.0.0.1' ended abnormally.
EXPLANATION:
The channel program running under process ID 15880(1112) for channel
'DEV.APP.SVRCONN' ended abnormally. The host name is '127.0.0.1'; in some cases
the host name cannot be determined and so is shown as '????'.
ACTION:
Look at previous error messages for the channel program in the error logs to
determine the cause of the failure. Note that this message can be excluded
completely or suppressed by tuning the "ExcludeMessage" or "SuppressMessage"
attributes under the "QMErrorLog" stanza in qm.ini. Further information can be
found in the System Administration Guide.
----- amqrmrsa.c : 630 --------------------------------------------------------
I am kind of stuck, I also saw in the log that there is PEER related info dumped, but I am not sing the SSLPEER settings (I just want to let everyone connect with the same certificate).
EDIT 2:
Output from RUNMQSC QM1 and command DISPLAY QMGR CONNAUTH:
1 : DISPLAY QMGR CONNAUTH
AMQ8408I: Display Queue Manager details.
QMNAME(QM1) CONNAUTH(DEV.AUTHINFO)
Output from RUNMQSC QM1 and command DISPLAY AUTHINFO(name-from-previous-command):
3 : DISPLAY AUTHINFO(DEV.AUTHINFO)
AMQ8566I: Display authentication information details.
AUTHINFO(DEV.AUTHINFO) AUTHTYPE(IDPWOS)
ADOPTCTX(YES) DESCR( )
CHCKCLNT(REQDADM) CHCKLOCL(OPTIONAL)
FAILDLAY(1) AUTHENMD(OS)
ALTDATE(2021-11-18) ALTTIME(15.09.20)
Output from DISPLAY CHLAUTH(*):
4 : DISPLAY CHLAUTH(*)
AMQ8878I: Display channel authentication record details.
CHLAUTH(DEV.ADMIN.SVRCONN) TYPE(USERMAP)
CLNTUSER(admin) USERSRC(CHANNEL)
AMQ8878I: Display channel authentication record details.
CHLAUTH(DEV.ADMIN.SVRCONN) TYPE(BLOCKUSER)
USERLIST(nobody)
AMQ8878I: Display channel authentication record details.
CHLAUTH(DEV.APP.SVRCONN) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(CHANNEL)
CHCKCLNT(REQUIRED)
AMQ8878I: Display channel authentication record details.
CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(CHANNEL)
AMQ8878I: Display channel authentication record details.
CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(NOACCESS)
I was expecting not having to provide username and password when using certificates. What am I missing here?
Your queue manager is configured to mandate passwords for any client connections that are trying to run with a resolved MCAUSER that is privileged. That is what CHCKCLNT(REQDADM) on your AUTHINFO(DEV.AUTHINFO) does.
In addition, your CHLAUTH rule for the DEV.APP.SVRCONN channel has upgraded this further to mandate passwords for ALL connections using that channel.
If your intent is to have channels that supply a certificate not be subject to this mandate, then you should add a further, more specific, CHLAUTH rule, something along these lines:-
SET CHLAUTH(DEV.APP.SVRCONN) TYPE(SSLPEERMAP) +
SSLPEER('SERIALNUMBER=61:9B:A4:3E,CN=DESKTOP-ROH98N2,C=NL') +
SSLCERTI('CN=DESKTOP-ROH98N2,C=NL') CHCKCLNT(ASQMGR) USERSRC(CHANNEL)
Bear in mind that if this connection is asserting a privileged user id, it will still be required to supply a password from the system-wide setting of CHCKCLNT(REQDADM).
Remember, if you are ever unsure which CHLAUTH rule you are matching against, all those details you saw in the error message can be used to form a DISPLAY CHLAUTH command to discover exactly which rule you have matched. Read more about that in I’m being blocked by CHLAUTH – how can I work out why?
I have a C client using OpenSSL that is failing a test when using a certificate that fails validation on the server side during the SSL_do_handshake() call on the server. When the application was using TLS 1.2 The SSL_do_handshake() failure on the server would be reported back to the client when it called SSL_do_handshake() as a failure return value.
When upgrading my application to OpenSSL 1.1.1 and TLS 1.3 I noted that while the validation error is still occurring on the server, it was no longer being reported back to the client.
I'm aware that the handshake protocol got completely re-written as part of TLS 1.3 however it seems like with all of the various callbacks available I should be able somehow on the client side to determine that authentication has failed without having to attempt to write data to the server.
Has anyone else encountered this and can they recommend a path forward?
The server and client in both TLSv1.2 and TLSv1.3 consider the handshake to be complete when they have both written a "Finished" message, and received one from the peer. This is what the handshake looks like in TLSv1.2 (taken from RFC5246):
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
So here you can see that the client sends its Certificate and Finished messages in its second flight of communication with the server. It then waits to receive the ChangeCipherSpec and Finished messages back from the server before it considers the handshake "complete" and it can start sending application data.
This is the equivalent flow for TLSv1.3 taken from RFC8446:
Client Server
Key ^ ClientHello
Exch | + key_share*
| + signature_algorithms*
| + psk_key_exchange_modes*
v + pre_shared_key* -------->
ServerHello ^ Key
+ key_share* | Exch
+ pre_shared_key* v
{EncryptedExtensions} ^ Server
{CertificateRequest*} v Params
{Certificate*} ^
{CertificateVerify*} | Auth
{Finished} v
<-------- [Application Data*]
^ {Certificate*}
Auth | {CertificateVerify*}
v {Finished} -------->
[Application Data] <-------> [Application Data]
One of the advantages of TLSv1.3 is that it speeds up the time taken to complete a handshake. In TLSv1.3 the client receives the "Finished" message from the server before it sends its Certificate and Finished messages back. By the time the client sends its "Finished" message, it has already received the "Finished" and so the handshake has completed and it can immediately start sending application data.
This of course means that the client won't know whether the server has accepted the certificate or not until it next reads data from the server. If it has been rejected then the next thing the client will read will be a failure alert (otherwise it will be normal application data).
I'm aware that the handshake protocol got completely re-written as part of TLS 1.3 however it seems like with all of the various callbacks available I should be able somehow on the client side to determine that authentication has failed without having to attempt to write data to the server.
It's not writing data to the server that is important - it is reading data. Only then will you know whether the server has sent an alert or just normal application data. Until that data has been read there are no callbacks available in OpenSSL that will tell you this - because OpenSSL itself does not know due to the underlying protocol.
We are migrating to WAS 8.5.5 and TLS 1.2 and are observing some unexpected problems.
The inputs are:
Worklight 6.1.0.1
WAS 8.5.5.9 + SDK Java 8
WAS is switched to TLS 1.2 (following this guide
https://developer.ibm.com/answers/questions/206952/how-do-i-configure-websphere-application-server-ss.html)
Application is Hybrid
When we use application via web emulator - it works fine.
When we use it from hardware device (Android or iOS) via IMC - we get exception that says
"client" uses TLS 1.1
server uses TLS 1.2
error of HTTPS handshake
It's not clear what is "client" in that case and why it uses TLS v1.1.
iOS device (iPhone) web browser is TLS 1.2 enabled - can open HTTPS links with TLS 1.2 protocol.
Here is full stack trace from SystemOut.log
[6/14/16 11:16:32:197 EDT] 000000b2 SSLHandshakeE E SSLC0008E: Unable to initialize SSL connection. Unauthorized access was denied or security settings have expired. Exception is javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1.1 not enabled or not supported
at com.ibm.jsse2.C.z(C.java:532)
at com.ibm.jsse2.ap.b(ap.java:476)
at com.ibm.jsse2.ap.c(ap.java:112)
at com.ibm.jsse2.ap.wrap(ap.java:277)
at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:21)
at com.ibm.ws.ssl.channel.impl.SSLUtils.handleHandshake(SSLUtils.java:748)
at com.ibm.ws.ssl.channel.impl.SSLConnectionLink.readyInbound(SSLConnectionLink.java:567)
at com.ibm.ws.ssl.channel.impl.SSLConnectionLink.ready(SSLConnectionLink.java:296)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture$1.run(AsyncChannelFuture.java:205)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1881)
Caused by: javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1.1 not enabled or not supported
at com.ibm.jsse2.j.a(j.java:31)
at com.ibm.jsse2.ap.a(ap.java:11)
at com.ibm.jsse2.C.a(C.java:342)
at com.ibm.jsse2.C.a(C.java:100)
at com.ibm.jsse2.E.a(E.java:140)
at com.ibm.jsse2.E.a(E.java:813)
at com.ibm.jsse2.C.r(C.java:44)
at com.ibm.jsse2.C$b.a(C$b.java:2)
at com.ibm.jsse2.C$b.run(C$b.java:3)
at java.security.AccessController.doPrivileged(AccessController.java:686)
at com.ibm.jsse2.C$c.run(C$c.java:11)
at com.ibm.ws.ssl.channel.impl.SSLUtils.handleHandshake(SSLUtils.java:835)
... 8 more
I have no idea what our next steps should be.
Any help will be much appreciated.
Seems pretty clear that TLSv1.2-only is too aggressive for your clients. In terms of WAS config, "ssl_tlsv2" is probably the best you can do.
IMC was causing it. Had to configure it to start using TLS v1.2
I do not understand the origin of this issue:
com.ibm.sslite.d: reason=2; alert=40; exception=null
It happens when i call:
int statusCode = httpClient.executeMethod(method);
It might be related to the SSL protocol and maybe websphere is quite old and incompatible.
12:56:46 [sid=] [uid=] [oid=] - ERROR com.darty.ecom.frontoffice.newespaceclient.core.service.cev.CevProxyConnection - CEV > STACK TRACE >
com.ibm.sslite.d: reason=2; alert=40; exception=null
at com.ibm.sslite.m.a(m.java:50)
at com.ibm.sslite.t.b(t.java:113)
at com.ibm.sslite.t.a(t.java:43)
at com.ibm.sslite.a.read(a.java:7)
at com.ibm.jsse.a.read(Unknown Source)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:200)
at java.io.BufferedInputStream.read(BufferedInputStream.java:218)
at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:77)
at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:105)
at org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1115)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1373)
at org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1832)
at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1590)
at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:995)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:397)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:324)
at com.darty.ecom.frontoffice.newespaceclient.core.service.cev.CevProxyConnection.executeMethod(CevProxyConnection.java:137)
the same error in the integration environmenent is a little different and says:
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
That means the server-side sent a TLS alert telling you the handshake failed. (alert#40) You'll need to debug the why on the server -- maybe it requries TLS client authentication, maybe your client only uses ancient protocols/ciphers or visa versa.
I'm running into a bit of a problem with my WCF service that is trying to talk to a Java Web Service.
I have a ASP.Net MVC front end that is talking to a WCF service over HTTP. The WCF service then talks to a JAVA web service over HTTPS utilising mutual authentication of certificates. The problem currently is that I am getting the following error when the WCF service trys to call the JAVA backend:
Could not establish secure channel for SSL/TLS
On the Java side, I am running JBOSS, with SSL3 and TLS ciphers for the SSL only. The error I have on that end is:
21:49:48,701 INFO [STDOUT] http-0.0.0.0-8543-2, WRITE: TLSv1 Handshake, length = 1514
21:49:49,499 INFO [STDOUT] http-0.0.0.0-8543-2, received EOFException: error
21:49:49,499 INFO [STDOUT] http-0.0.0.0-8543-2, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
21:49:49,507 INFO [STDOUT] http-0.0.0.0-8543-2, SEND TLSv1 ALERT: fatal, description = handshake_failure
21:49:49,507 INFO [STDOUT] http-0.0.0.0-8543-2, WRITE: TLSv1 Alert, length = 2
21:49:49,507 INFO [STDOUT] http-0.0.0.0-8543-2, called closeSocket()
21:49:49,508 INFO [STDOUT] http-0.0.0.0-8543-2, called close()
As I'm using mutual authentication of certs, my first port of call was bad certificate. So I have opened up the service wsdl page (also requires authentication of cert), and everything is ok. My Certificates are fine and trusted.
I then started thinking that maybe the cert is not getting put on the service call. So I created a console app that calls the Java service with the same certifcate (looked up via an endpoint behaviour in the config file). Lo and behold, this work fine, and the service response data is shown on the screen.
So that leaves me thinking that there is something in IIS that is stopping the SSL channel being opened, and this is where I need a bit of help really.
My IIS is version 7.0 running on Windows Server 2008 R2. The service is running on .Net 4.
(One thing I should point out was that my consle app was running .Net v3.5 not v4.)
I have dabbled a bit in the SCHANNEL settings, but don't really know which settings should be enabled, and which should be disabled.
Currently I have:
TLS 1.0/Server/Enabled = 1
SSL 3.0/Server/Enabled = 1
SSL 2.0/Server/Enabled = 1
PCT 1.0/Server/Enabled = 1
I also have:
SSL 2.0/Client/DisabledByDefault = 0
Does anyone have any ideas on where to start?
Thanks in advance,
Nick
[UPDATE]
Am now getting the following error in the Windows Error Log:
A fatal error occurred when attempting to access the SSL client credential private key.
The error code returned from the cryptographic module is 0x8009030d.
The internal error state is 10003.
...but I'm not sure to resolve it. The certifcate is being picked up ok by the looks of this. it just can't get the password.
[Answered]
It turns out that the priviledges on the Certificate hadn't been set for my IIS_IUSRS account.
When I set those up, everything worked fine.