does anyone who tried MQTT connection with security for the new SDK MQTT client example

my configure of usr_connect_config just like following
/////////////////////////////////////////////////////////////////////////////////////

char *security_file_list[] = {NULL, NULL, "/cert/mosquitto.org.crt", NULL};
/* connection configuration */
connect_config usr_connect_config[] =
{
{
{
{
SL_MQTT_NETCONN_SEC,
SERVER_ADDRESS,
PORT_NUMBER,
4,
SL_SO_SEC_METHOD_SSLV3,//checking it out in socket.h
SL_SEC_MASK_SSL_RSA_WITH_RC4_128_SHA,//checking it out in socket.h line 314
security_file_list
},
SERVER_MODE,
true,
},
NULL,
"user1",
NULL,
NULL,
true,
KEEP_ALIVE_TIMER,
{Mqtt_Recv, sl_MqttEvt, sl_MqttDisconnect},
TOPIC_COUNT,
{TOPIC1, TOPIC2, TOPIC3},
{QOS2, QOS2, QOS2},
{WILL_TOPIC,WILL_MSG,WILL_QOS,WILL_RETAIN},
false
}
};
/////////////////////////////////////////////////////////////////////////////////////

the /mosquitto.org.crt file i got it from http://test.mosquitto.org/, and
/////////////////////////////////////////////////////////////////////////////////////
/*Defining Broker IP address and port Number*/
#define SERVER_ADDRESS "test.mosquitto.org"//"messagesight.demos.ibm.com"
#define PORT_NUMBER 8883
/////////////////////////////////////////////////////////////////////////////////////

here is my debug output of mqtt client example codes:
/////////////////////////////////////////////////////////////////////////////////////
Host Driver Version: 1.0.0.10
Build Version 2.0.7.0.31.0.0.4.1.1.5.3.3
Device is configured in default state
Started SimpleLink Device: STA Mode
[WLAN EVENT] STA Connected to the AP: Mysys_2.4GHz_3AF5 , BSSID: 50:bd:5f:e4:3a:f5
[NETAPP EVENT] IP acquired by the device

Device has connected to Mysys_2.4GHz_3AF5
Device IP Address is 192.168.2.104

Version: Client LIB 1.0.3, Common LIB 1.1.1.

Broker connect fail for conn no. 1

Exiting the Application
/////////////////////////////////////////////////////////////////////////////////////
always show me connect fail to Broker, any idea for this issue?
Thank you

Thank you for directing me to that post.  I dont know if the SSL Demo app will help me since it seems to use different functions to connect to a SSL server VS the MQTT libraries?  Either way, the original poster had some hints in the code he posted that pointed to where I can specify SSL cipher and methods in the connection configuration like this:

connect_config usr_connect_config[] =

{{{{
SL_MQTT_NETCONN_SEC,
SERVER_ADDRESS,
PORT_NUMBER,
4,
SL_SO_SEC_METHOD_SSLV3,//checking it out in socket.h
SL_SEC_MASK_SSL_RSA_WITH_RC4_128_SHA,//checking it out in socket.h line 314
security_file_list
},

 

Is there any further documentation that describes this specific structure and the various parameter inputs that are accepted?

I looked through the SDK documentation and found no references to SSL methods and ciphers.  

I havent yet tried this yet, but I should have some time this weekend and will post back here to help other people who might have the same questions in the future.

Thanks in advance,

I am similar issues as TieXue. I am testing with the Mosquitto MQTT broker.  

My CA /server keys and certs were generated using generate-CA.sh https://github.com/owntracks/tools/blob/master/TLS/generate-CA.sh , and I generated the client key and cert manually using openssl in .der format.  The client key and cert, converted to PEM format, worked with mosquitto_pub/sub with the secured broker without issue.  Using UniFlash, I transfer the client key and cert and the ca cert to the application flash in /cert/<file name>. 

In main.c, I updated the usr_connect_config to the following

char *security_file_list[] = {"/cert/clientkey.der", "/cert/clientcrt.der", "/cert/cacrt.der"};

connect_config usr_connect_config[] =
{
    {
        {
            {
                SL_MQTT_NETCONN_SEC,  //SL_MQTT_NETCONN_URL
                SERVER_ADDRESS,
                PORT_NUMBER,
		SL_SO_SEC_METHOD_SSLv3_TLSV1_2,
		SL_SEC_MASK_SECURE_DEFAULT,
                3,
		security_file_list
            },
            SERVER_MODE,
            true,
        },
        NULL,
        "user1",
        NULL,
        NULL,
        true,
        KEEP_ALIVE_TIMER,
        {Mqtt_Recv, sl_MqttEvt, sl_MqttDisconnect},
        TOPIC_COUNT,
        {TOPIC1, TOPIC2, TOPIC3},
        {QOS2, QOS2, QOS2},
        {WILL_TOPIC,WILL_MSG,WILL_QOS,WILL_RETAIN},
        false
    }
};

The result is that the Status returned by sl_Connect() is SL_ECONNREFUSED (-111) in comm_open() function in cc31xx_sl_net.c. 

With this same project in its original state, except for the server address, and the Mosquitto broker in default unsecured configuration, the connection was successful and  basic function all worked.

Also, I did test the ssl project per the instructions with no issues.

Best,

Scott

Scott,

I have also generated my SSH keys with that same .sh file.  I followed this blog post to help me set it up: rockingdlabs.dunmire.org/.../ssl-client-certs-to-secure-mqtt

I configured the same way as your code and also cannot connect.  I have also tried other various methods and ciphers like 

SL_SO_SEC_METHOD_TLSV1_2

SL_SEC_MASK_SSL_RSA_WITH_RC4_128_SHA

No combinations seem to work....everything works as expected when connecting to the non-SSL port.

I get a different error though, and I cannot make any sense of it:

Device has connected to TheInternet                                          
Device IP Address is 192.168.2.12                                                                              
                                           
Version: Client LIB 1.0.3, Common LIB 1.1.1.                                  
C: FH-B1 0x10 to net 17, Sent (64 Bytes) [@ 7]                               
C: Net 17, Raw Error -1, Time Out: N                                         
C: RX closing Net 17 [-1]                                                    
C: Cleaning session for net 17                                                 
C: Net 17 now closed                                                                                                                                        
                                    
Broker connect fail for conn no. 1 

I have verified that other devices can connect to this SSL port via websockets

Hello Justin,

I just tried this with HiveMQ with the same results as with Mosquitte.

Also, I setup openssl s_server as the target server, and it is clearly sending a server cert (same one used with Mosquitto) to the cc3200. After that, the data looks encryted as seen in wireshark. This, of course, fails because it doesn't talk MQTT. Based on that, I changed my mosquitto conf to not require a client cert (require_certificate false). But this did not have effect.

Best,
Scott

Hi Scott,

My require_certificate flag is also set to false.  

What is the error message that you see over the CC3200 UART?  Is it similar to the one I see?  

I do not see the -111 connection error that you spoke about, but a "timeout" error.  I do not think it is a timeout since the message comes immediately after I attempt to connect with the MQTT broker.

To give a little more detail on how I know the SSL MQTT broker is configured correctly:

I have a  Macbook Pro running the software MQTT.fx.  MQTT.fx will connect to the SSL port as long as I provide the client key, client certificate, and CA certificate.  I also had to use openssl to convert the SSL certificates to a different format (I think .DER?) in order for MQTT.fx to accept the certificates.

Once the certs were in the correct format, and I had selected SSLv3, I was able to connect successfully.

I tried to use the .DER(?) converted files within the CC3200 but I still get the same error message.

I can also connect over websockets on an https website via a different port (over SSL).

Hi Justin,

Here is the output on my serial terminal:

Host Driver Version: 1.0.0.10

Build Version 2.4.7.2.31.0.0.3.0.1.1.8.8

Device is configured in default state

Started SimpleLink Device: STA Mode

[WLAN EVENT] STA Connected to the AP: OFFICE , BSSID: d8:67:d9:c4:32:df

[NETAPP EVENT] IP acquired by the device

Device has connected to OFFICE

Device IP Address is 192.168.2.246

Version: Client LIB 1.0.3, Common LIB 1.1.1.

Broker connect fail for conn no. 1

Exiting the Application

The -111 error code is from the sl_Connect function (Line:290) when it is called in the comm_open function (Line:218) in cc31xx_sl_net.c. Otherwise the real connection status is not return to any higher point in the code.

Also, I repeated the certificate and key generation based on the rockingdlabs link you provided, and converted the client cert/key and ca cert into .der format. It still failed to connect.

I am running the Mosquitto broker v1.42 (from a PPA) on a Ubuntu 14.04LTS. The keys and certs, in the default PEM format,  work perfectly with the mosquitto_sub and pub clients with this setup.

So, I am still scratching my head. I've submitted the issue to TI support. Hopefully, a FAE will get back to me soon. 

Best,

Scott

Hey Scott,

Really appreciate the replies.  It looks as though we have an almost identical broker setup:  Amazon EC2 + Ubuntu 14.04 + Mosquitto 1.42 broker --> CC3200 client.  It also looks like we are getting different  printouts.  Like you, I get the broker failed to connect message, but my printout is a little bit more detailed:

Version: Client LIB 1.0.3, Common LIB 1.1.1.                                  

C: FH-B1 0x10 to net 17, Sent (64 Bytes) [@ 7]                              

C: Net 17, Raw Error -1, Time Out: N                                        

C: RX closing Net 17 [-1]                                                    

C: Cleaning session for net 17                                                

C: Net 17 now closed  

Broker connect fail for conn no. 1

Any idea what Net 17 is?

Also - when you say "The keys and certs, in the default PEM format,  work perfectly with the mosquitto_sub and pub clients with this setup."  Does that mean you were actually able to get SSL working with the SSH key generator script with the CC3200??  Do you mean the keys stored in the CC3200 by default?  I have not been able to get SSL working at all with the CC3200.

Its possible the only reason I had to convert it to .DER format was because the MQTT OSX application I was using was written in java and that just happened to be the format it expected. 

Hello Justin,

The Net "17" appears to originate in the sl_Socket function in socket.c as part of a response from the network processor in the CC3200. Basically, it seems to be your socket number or index.

Yes, your printout does look more extensive then mine. I think your system may have be successfully negotiated the TLS part, but your broker isn't responding. I say that because 0x10 is a MQTT Connect Command. Also, your output looks similar to what I get when I use the openssl s_server program in place of Mosquitto.

The statement "The keys and certs, in the default PEM format ... " referred to uses of the generate-CA.sh and manually generating the client key and certificate with openssl. I have only successfully used these keys and certs with the Mosquitto clients connecting to the broker. I also still have had no success connecting the CC3200.

I am in contact with TI Applications dept, and advised them about the issue I am having and this forum thread. The engineer advised me to change my security mask from SL_SEC_MASK_TLS_RSA_WITH_AES_256_CBC_SHA to SL_SEC_MASK_TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA. That didn't help me. Also, there is another forum thread that appear to have solved the problem, e2e.ti.com/.../417213

I will update you with any feedback I get from TI.

Best,
Scott

Hey Scott,

Really appreciate the replies :) I tried the engineers suggestion for changing security mask to SL_SEC_MASK_TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA and it didnt help me either.

I just looked through the generate-CA.sh script again and I may have found something but have not been able to try it yet...I wanted to see exactly how it was generated the SSL scripts again, and I noticed this line:

defaultmd="-sha512"

the line with -sha256 is commented out. This variable is used everytime a key or certificate is generated.

I havent been able to try it using -sha256 yet, but perhaps the certificates and keys we are generating were actually SHA512 which I dont think the CC3200 can support?

I will write back when I have a chance to try this.

Hi Justin/Scott,

I think we should debug this step by step

• Step 1: Use the ssl example provided in the example to connect to the server without using CA certificate. This will help us identify the correct cipher and security method. For this you will have to modify the ssl example as per below.

#if 0
//
//configure the socket with GOOGLE CA certificate - for server verification
//
lRetVal = sl_SetSockOpt(iSockID, SL_SOL_SOCKET, \
					   SL_SO_SECURE_FILES_CA_FILE_NAME, \
					   SL_SSL_CA_CERT_FILE_NAME, \
					   strlen(SL_SSL_CA_CERT_FILE_NAME));

if(lRetVal < 0)
{
	UART_PRINT("Device couldn't set socket options \n\r");
	GPIO_IF_LedOn(MCU_RED_LED_GPIO);
	return lRetVal;
}
#endif

/* connect to the peer device - Google server */
lRetVal = sl_Connect(iSockID, ( SlSockAddr_t *)&Addr, iAddrSize);

if((lRetVal < 0) && (SL_ESECSNOVERIFY !=Status))
{
	UART_PRINT("Device couldn't connect to Google server \n\r");
	GPIO_IF_LedOn(MCU_RED_LED_GPIO);
	return lRetVal;
}

On success the sl_Connect() will return with -453 error code (SL_ESECSNOVERIFY)

• Step 2: Revert to the original ssl example and try connecting using certificate.
• Step 3: Try connecting to server and communicating using the MQTT example.

Regards,

Ankur

Hello Ankur,

Thank you for helping us with this problem.

My results:
Step 1[ssl]: sl_Connect returned -453(SL_ESECSNOVERIFY) error code
Step 2[ssl]: sl_Connect returned 0 (SL_SOC_OK) error code
Step 3[mqtt_client]: sl_Connect returned -111 (SL_ECONNREFUSED) error code ( sl_Connect call location: comm_open in cc31xx_sl_net.c);
Target : Local Mosquitto broker with the earlier stated configuration.

Best,
Scott

Hi Justin,

I tried changing the message digest to sha256 in the script. But it did not appear to have any effect.

Also, Ankur from TI has join our thread to assist us in resolving this issue.

Best,
Scott

Did you modify the Macro in the ssl example to connect to the MQTT server with which you are attempting connection in MQTT example?

Regards,
Ankur

Hello Ankur,

Yes, I did also modify the ssl example to target the MQTT broker using only the ca certificate and using the client key & certificate and the ca certificate. In both cases, the sl_Connect function returns -111 (SL_ECONNREFUSED). Note, all of the keys and certificates were generate with the generate-CA.sh script previously referenced

Best,
Scott

Hi Ankur, 

I was unable to get any printouts when debugging the SSL example last night.  The unmodified example seems to not print anything over UART?

Aside from that, it seemed like the point of this exercise was to figure out which methods and ciphers are supported by my server/certificates, so I installed nmap on my OSX system and ran the following command:

https://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html         nmap --script ssl-enum-ciphers -p 443 <host>

The output of this command when running it on my server and port 8883 (my SSL port) listed TLS 1.0, 1.1, and 1.2, as well as every cipher that is currently supported by the CC3200.

For completeness of this post, here is the output from the NMAP printout for TLS 1.2:

|   TLSv1.2: 

|     ciphers: 

|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (dh 256) - A

|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (dh 256) - A

|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (dh 256) - A

|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A

|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A

|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A

|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A

|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 256) - C

|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C

|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (dh 256) - A

|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (dh 256) - A

|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (dh 256) - A

|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A

|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A

|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A

|       TLS_RSA_WITH_SEED_CBC_SHA (rsa 2048) - A

|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A

|       TLS_ECDHE_RSA_WITH_RC4_128_SHA (dh 256) - A

|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A

|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - A

|     compressors: 

|       NULL

|     cipher preference: server

|     warnings: 

|       Ciphersuite uses MD5 for message integrity

|       Weak cipher RC4 in TLSv1.1 or newer not needed for BEAST mitigation

|_  least strength: C

Hi Scott/Justin,

Will it be possible for you to share the sniffer logs for the connection session?

Regards,
Ankur

Hi Justin,

I ran into the same issue with ssl example not have any serial output. Here how I solved that.

Add the following files to the project:
- uart_if.c
- uart_if.h
Both are found in the ...\CC3200SDK_1.1.0\cc3200-sdk\example\common directory

Remove the "NOTERM" symbol from Properties > C/C++ Build > Settings > ARM Compiler > Advanced Options > Predefined Symbols > Pre-define NAME.

Then you should you should get the serial printout.

Best,
Scott

Hello Ankur,

After spending the weekend going through the mosquitto.conf, I found the source the problem. In the Default listener section there is a setting called bind_address that was set to 127.0.0.1. This was preventing any external client from connecting. Apologies for that goose chase on that.

Once, this was corrected a new error code, SL_ESECDATEERROR (-461) was being returned by the sl_Connect function. This indicated a date verification error with certificate. I borrowed the time setting code from the ssl example, and summarily resolved that verification issue with the certificates. Is there a best practice from TI to handle this situation, or should I be implementing NTP and setting the time/date per the ssl example?


Thanks,
Scott

Hi Scott,

Thanks for the update.

You can use NTP to update the time of the NWP once on reset and the time will be maintained by the system over hibernate cycle.
You can find the example for the same under SDK (get_time).

Regards,
Ankur

Scott thanks for helping fix the SSL example.  Now that I can see the UART printouts, here is what happened for me:

Step 1: I had to change method and cipher as follows in function ssl():

unsigned char    ucMethod = SL_SO_SEC_METHOD_TLSV1_2;//SL_SO_SEC_METHOD_SSLV3;

 unsigned int uiIP,uiCipher = SL_SEC_MASK_TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA;//SL_SEC_MASK_SSL_RSA_WITH_RC4_128_SHA;=

After changing the method and cipher, I got the expected outcome for step 1.

Step 2: It looks like I get an error -456. This, as I understand it, means a bad CA file.

I am having a bit of trouble figuring out why my CA file is bad as it seems to work for other clients.  I

I also tried converting my CA cert to a DER format as explained on this page http://processors.wiki.ti.com/index.php/CC32xx_Serial_Wifi:

 openssl x509 -in <input.crt> -inform PEM –out <output.crt> -outform DER 

I dont know if it will help. but I have uploaded my ca.crt and ca2.DER file.  They are located on my CC3200 at /cert/ca.crt and cert/ca2.der

The location I state in my CC3200 firmware is this format:

#define SL_SSL_CA_CERT_FILE_NAME        "/cert/ca2.der"

cacerts.zip

Hi Justin,

In my setup, I'm loading three files on to the cc3200, /cert/cacrt.der, /cert/clientcrt.der, and /cert/clientkey.der . I used the generate-CA.sh to generate the ca, server, and client certs and keys. These are in the PEM format by default. As you did above, I used openssl to change the format to DER. I then tested the DER formatted certs and key with MQTT.fx since it can use either format. Once verified, I loaded onto cc3200 using Uniflash.

Here is the config section in my main.c:

#define SERVER_ADDRESS          "192.168.2.137"

#define PORT_NUMBER             8883

char *security_file_list[] = {"/cert/clientkey.der", "/cert/clientcrt.der", "/cert/cacrt.der"};

/* connection configuration */
connect_config usr_connect_config[] =
{
    {
        {
            {
SL_MQTT_NETCONN_SEC,
SERVER_ADDRESS,
PORT_NUMBER,
              SL_SO_SEC_METHOD_TLSV1_2,
              SL_SEC_MASK_TLS_RSA_WITH_AES_256_CBC_SHA256,
              3,
              security_file_list
            },
            SERVER_MODE,
            true,
        },
        NULL,
        "user1",
        NULL,
        NULL,
        true,
        KEEP_ALIVE_TIMER,
        {Mqtt_Recv, sl_MqttEvt, sl_MqttDisconnect},
        TOPIC_COUNT,
        {TOPIC1, TOPIC2, TOPIC3},
        {QOS2, QOS2, QOS2},
        {WILL_TOPIC,WILL_MSG,WILL_QOS,WILL_RETAIN},
        false
    }
};

generate-CA.sh  => https://github.com/owntracks/tools/blob/master/TLS/generate-CA.sh

Hope this helps.

Best,

Scott

Hi Scott,

Did you successfully connect to MQTT with TLS?

Thank you.

Best Regards,

Bryan

Hi Bryan,

Yes, I did manage to get encrypted MQTT connections between several cc3200 lauchpad board and Mosquitto brokers. My post from Aug 25 details my basic cc3200 configuration. Are you having a problem?

Best,
Scott

Hi Scott,

Thanks for your reply.
I tried the MQTT with TSL about 2 weeks
but no idea how to configure it.
I am also using Mosquito brokers with TSLv1_2
but I cannot get encrypted MQTT connections.
I tried these two website to generate the key
lukse.lt/.../
rockingdlabs.dunmire.org/.../ssl-client-certs-to-secure-mqtt
and the .der file can connect to my server with MQTT.fx.
And no idea why CC3200 cannot connect to my server.
I have tried all ciphers.
Can you share how to set up the TLS with mosquito?

Thank you.
Bryan

Hi Bryan,

Here is important section of mosquitto.conf:

# =================================================================
# Default listener
# =================================================================

# IP address/hostname to bind the default listener to. If not
# given, the default listener will not be bound to a specific
# address and so will be accessible to all network interfaces.
# bind_address ip-address/host name
#bind_address

# Port to use for the default listener.
port 8883

# The maximum number of client connections to allow. This is
# a per listener setting.
# Default is -1, which means unlimited connections.
# Note that other process limits mean that unlimited connections
# are not really possible. Typically the default maximum number of
# connections possible is around 1024.
#max_connections -1

# Websockets support is currently disabled by default at compile time.
# Certificate based TLS may be used with websockets, except that
# only the cafile, certfile, keyfile and ciphers options are supported.
protocol mqtt

# When a listener is using the websockets protocol, it is possible to serve
# http data as well. Set http_dir to a directory which contains the files you
# wish to serve. If this option is not specified, then no normal http
# connections will be possible.
#http_dir

# Set use_username_as_clientid to true to replace the clientid that a client
# connected with with its username. This allows authentication to be tied to
# the clientid, which means that it is possible to prevent one client
# disconnecting another by using the same clientid.
# If a client connects with no username it will be disconnected as not
# authorised when this option is set to true.
# Do not use in conjunction with clientid_prefixes.
# See also use_identity_as_username.
#use_username_as_clientid

# -----------------------------------------------------------------
# Certificate based SSL/TLS support
# -----------------------------------------------------------------
# The following options can be used to enable SSL/TLS support for
# this listener. Note that the recommended port for MQTT over TLS
# is 8883, but this must be set manually.
#
# See also the mosquitto-tls man page.

# At least one of cafile or capath must be defined. They both
# define methods of accessing the PEM encoded Certificate
# Authority certificates that have signed your server certificate
# and that you wish to trust.
# cafile defines the path to a file containing the CA certificates.
# capath defines a directory that will be searched for files
# containing the CA certificates. For capath to work correctly, the
# certificate files must have ".crt" as the file ending and you must run
# "c_rehash <path to capath>" each time you add/remove a certificate.
cafile /etc/mosquitto/ca_certificates/ca.crt
#capath

# Path to the PEM encoded server certificate.
certfile /etc/mosquitto/certs/server.crt

# Path to the PEM encoded keyfile.
keyfile /etc/mosquitto/certs/server.key

# This option defines the version of the TLS protocol to use for this listener.
# The default value allows v1.2, v1.1 and v1.0, if they are all supported by
# the version of openssl that the broker was compiled against. For openssl >=
# 1.0.1 the valid values are tlsv1.2 tlsv1.1 and tlsv1. For openssl < 1.0.1 the
# valid values are tlsv1.
#tls_version

# By default a TLS enabled listener will operate in a similar fashion to a
# https enabled web server, in that the server has a certificate signed by a CA
# and the client will verify that it is a trusted certificate. The overall aim
# is encryption of the network traffic. By setting require_certificate to true,
# the client must provide a valid certificate in order for the network
# connection to proceed. This allows access to the broker to be controlled
# outside of the mechanisms provided by MQTT.
require_certificate true

# If require_certificate is true, you may set use_identity_as_username to true
# to use the CN value from the client certificate as a username. If this is
# true, the password_file option will not be used for this listener.
#use_identity_as_username false

# If you have require_certificate set to true, you can create a certificate
# revocation list file to revoke access to particular client certificates. If
# you have done this, use crlfile to point to the PEM encoded revocation file.
#crlfile

# If you wish to control which encryption ciphers are used, use the ciphers
# option. The list of available ciphers can be optained using the "openssl
# ciphers" command and should be provided in the same format as the output of
# that command.
# If unset defaults to DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2:@STRENGTH
#ciphers DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2:@STRENGTH


I'm using both client and server certificates instead of the clients using login/password to authenticate clients with the broker. Hence, the "require_certificate true" setting. This can be set "false" if your planning to use login/password or not have the broker authenticate the clients. Then, you should only the ca file load on the device.

If you are running mosquitto on a Ubuntu Linux system, there is an example conf file with the comments you see above stored in "/usr/share/doc/mosquitto/example/mosquitto.conf.gz". These comments have been very helpful in figuring out the right configuration.

Best,
Scott

Hi Scott,

Thanks a lot.

Do I need to configure cipher?

I tried use both CA only and with client key

but still not worked.

Do you think it is correct to generate the key shown on above link?

I can use the key to connect on Mqtt. fx.

Thank you.

Best Regards,

Bryan

Hi Scott,

I tried your setting but it still not work.
I think maybe something wrong on my cert.
For CA-only:
I follow this guide: http://lukse.lt/uzrasai/2015-02-internet-of-things-messaging-mqtt-1-installing-mosquitto-server/

Also, I have tried to follow TI's guide and generate CA file:

openssl genrsa -out privkey.pem 2048

openssl rsa -in privkey.pem -inform PEM -out privkey.der -outform DER

openssl req -new -x509 -days 3650 -key privkey.pem -out root-ca.pem

openssl req -new -key privkey.pem -out cert.pem

openssl x509 -req -days 20000 -in cert.pem -CA root-ca.pem -CAkey privkey.pem -set_serial 01 -out cert.pem

openssl x509 -in root-ca.pem -inform PEM -out ca.der -outform DER

openssl x509 -in cert.pem -inform PEM -out cert.der -outform DER

And for TSL with client key:
rockingdlabs.dunmire.org/.../ssl-client-certs-to-secure-mqtt
Do you think I can follow them to set up the TSL using CC3200?

To convert the key file, I use openssl:
#change cert format (from .crt to .der)
openssl x509 -in certificate.crt -out certificate.der -outform der

For .key file:
I change .key to .pem then use above command.

All above settings, I can use the cert file on MQTT.fx but not on CC3200.

In uniflash:

Is there anything wrong?

Thank you very much.

I am glad that you said you successfully use a encrypted MQTT with CC3200

as I tried it about 2 weeks and tried to think whether it is possible to use CC3200 with encrypted MQTT.

Thanks a lot.

Best Regards,

Bryan

Hi Scott,

For configuration in CC3200.
I followed your configuration:
/*Defining Broker IP address and port Number*/
#define SERVER_ADDRESS "52.XX.XX.XXX"
#define PORT_NUMBER 8883

#define MAX_BROKER_CONN 1

#define SERVER_MODE MQTT_3_1_1

char *security_file_list[] = {"/cert/clientkey.der", "/cert/clientcrt.der", "/cert/ca.der"};

/* connection configuration */
connect_config usr_connect_config[] =
{
{
{
{
SL_MQTT_NETCONN_SEC, /**< Enumerate connection type */
SERVER_ADDRESS, /**< Server Address: URL or IP */
PORT_NUMBER, /**< Port number of MQTT server */
SL_SO_SEC_METHOD_TLSV1_2, //0 /**< Method to tcp secured socket */
SL_SEC_MASK_TLS_RSA_WITH_AES_256_CBC_SHA256, //0, /**< Cipher to tcp secured socket */
3, //0, /**< Number of files for secure transfer */
security_file_list, //NULL /* SL needs 4 files*/
},
SERVER_MODE,
true,
},
NULL,
(unsigned char*) "user_1",
NULL,
NULL,
true,
KEEP_ALIVE_TIMER,
{Mqtt_Recv, sl_MqttEvt, sl_MqttDisconnect},
TOPIC_COUNT,
{TOPIC1, TOPIC2}, //, TOPIC3},
{QOS2, QOS2}, //, QOS2},
{WILL_TOPIC,WILL_MSG,WILL_QOS,WILL_RETAIN},
false
}
};

Thank you.

Best Regards,
Bryan

Hi Bryan,

I would suggest using "generate-CA.sh" from OwnTracks.org. They did a real good job with this script. The only change I made was the to defaultmd (around line 80) . You'll need to change its value to the number of SHA bits you are using for the message digest of your certificates. Then, use openssl to convert pem format from the der format.

By the way, MQTTFx can use either pem or der format keys and certs.

Also, I would running the script and broker on the same computer at first. The server certs are generated with host system's ip by default, and the clients verify this. Then, start using the IPLIST and HOSTLIST environmental variable to configuration the server certs for other hosts.

generate-CA.sh => github.com/.../generate-CA.sh

Best,
Scott

Hi Scott,

Thanks for your help.
I used generate-CA.sh and change SHA bits to SHA256.
And I tried to change .crt to .der on following command:
openssl x509 -in ca.crt -out ca.der -outform der

As I want to tried only CA first.
I set it:
char *security_file_list[] = {0, 0, "/cert/ca.der"};

/* connection configuration */
connect_config usr_connect_config[] =
{
{
{
{
SL_MQTT_NETCONN_SEC, /**< Enumerate connection type */
SERVER_ADDRESS, /**< Server Address: URL or IP */
PORT_NUMBER, /**< Port number of MQTT server */
SL_SO_SEC_METHOD_TLSV1_2, //0 /**< Method to tcp secured socket */
SL_SEC_MASK_TLS_RSA_WITH_AES_256_CBC_SHA256, //0, /**< Cipher to tcp secured socket */
3, /**< Number of files for secure transfer */
security_file_list, //NULL /* SL needs 4 files*/
},
SERVER_MODE,
true,
},
NULL,
(unsigned char*) "user_1",
NULL,
NULL,
true,
KEEP_ALIVE_TIMER,
{Mqtt_Recv, sl_MqttEvt, sl_MqttDisconnect},
TOPIC_COUNT,
{TOPIC1, TOPIC2}, //, TOPIC3},
{QOS2, QOS2}, //, QOS2},
{WILL_TOPIC,WILL_MSG,WILL_QOS,WILL_RETAIN},
false
}
};

But dun know why it still cannot connect to broker.
Did you tried only CA?

Maybe I need to tried using it with client.
Is there any .sh file to generate client files?
Thank you very much.

Best Regards,
Bryan

Hi Scott,

Thanks for your help.
I found that you said I need to use IPLIST and HOSTLIST environmental variable.
I forgot to configure this.
I will try it.
Thank you very much.

Best Regards.
Bryan

Hi Scott,

Sorry for annoying a lot of times.

I am still making an effort to get an encrypted MQTT.

I dun know what is wrong that I cannot get it done.

Maybe I explain my step to set up it, can you help me?

First, I am using Ubuntu to set up the mosquito server.

After set it up, I start to generate SSL/TSL part.

To generate ca cert and server cert,

I use bash ./generate-CA.sh (AND it is changed to -sha256)

and to generate client cert,

I use following command:

openssl genrsa -out client.key 2048
openssl req -new -sha256 -out client.csr -key client.key -subj "/CN=client/O=example.com"
openssl x509 -req -sha256 -in client.csr -CA ca.crt -CAkey ca.key -CAserial ./ca.srl -out client.crt -days 3650 -addtrust clientAuth

And then, copy them to mosquito folders and change the mosquito.conf

As you said, I use the file extracted from mosquitto.conf.gz

and change the port to 8883, change the ca path and require_certificate to true.

And after that, I use sudo service mosquitto restart to restart mosquitto.

Then I change those cert file to .der file.

For .crt file, I use openssl x509 -in certificate.crt -out certificate.der -outform der

For .key file I use openssl rsa -in client.key -outform DER -out clientkey.der

Then the server is set.

I tried to use those file with mqtt.fx and it works fine.

So I flash them to CC3200 and modify the sample mqtt project.

But dun know why it cannot connect to broker.

I also tried do not use client file.

I am using the same router with CC3200

and I think the IPLIST is okay as I can use same IP with MQTT.fx.

Thank you very much.

Best Regards.

Bryan

Hi Bryan,

I would suggest using the generate-CA.sh script to generate the client certificates and keys also. The script's author configures the client certificates with a X509 extension that in specifies that it is a client certificate and other details.

My normal workflowis to:

1. export HOSTLIST and IPLIST environmental variables with the required dns and ip addresses
2. execute the script to generate CA and server certificates and keys   ./generate-CA.sh <broker_cert_name>
3. execute the script again to generate client certificates and keys    ./generate-CA.sh client <client_cert_name>  (in the same directory has the CA files)
4. execute openssl to translate pem files into der files
5. upload der versions of CA certificate and client certificate and key to CC3200 with uniflash

This has worked very well for me during my development and testing. Originally, I did generate the client certificates and keys by hand, but it was a very error prone process. Also, make sure that you point to the correct files in the app flash in the MQTT configuration. That little mistake cost me days.

Best,

Scott

I got MQTT with SSL working with the following changes to the generate-CA.sh
a. defaultmd="-sha512" defaultmd="-sha256"
b. $openssl genrsa -out $SERVER.key $keybits to $openssl genrsa -aes256 -out $SERVER.key $keybits
(note that I haven't figured out how to disable the password protection on the cert so it will prompt for a password)

I took the ca.crt, imported into chrome and then exported to der.cer and installed onto CC3200.

Then for the MQTT.c I made the following changes to the configuration variable:
#define MQTT_SSL_CERT "ca.der.cer"
static char *security_file_list1[] = {MQTT_SSL_CERT};
/* connection configuration */
static connect_config usr_connect_config[] =
{
{
{
{
(SL_MQTT_NETCONN_URL | SL_MQTT_NETCONN_SEC) ,
MQTT_TARGET_BROKER,
MQTT_PORT_NUMBER,
SL_SO_SEC_METHOD_TLSV1_2, // Mosquitto defaults to TLSV1_2 normally
0xff, // Cipher selection, in this case, we've selected them all
1, // Only one file needed, the certificate
security_file_list1 // Points to name of the file in CC3200 NV memory
},
....

Note that you MUST have set the time through slDevSet to something pretty recent so the certificate is valid.

YMMV and hope it helps. Really wish TI's documentation was better:s

Hi Scott and halfbit;drop,

Thanks a lot.
I finally got my encrypted MQTT.
Many thanks.

I am using Scott suggestion to create the certificate
and set up the MQTT server.

And thanks for halfbit;drop that remind me to set the time on CC3200.
After setting the time, I got my encrypted MQTT.

Thank Scott and halfbit;drop very much.

Best Regards,
Bryan

Hello everyone,

Even if almost 2 year have passed, I'm posting on this thread because I have the same problems of you connecting to MQTT broker via TLS.

For Justin: your printout is more detailed because you have enabled extra debug in MqttClientLibCfg:

SlMqttClientLibCfg_t Mqtt_Client=
{
    0,
    TASK_PRIORITY,
    30,
    true,
    (long(*)(const char *, ...))UART_PRINT   //NULL
};

The Net 17 you see in those debugs I think is a number the library assign to each open socket,

when I run the mqtt server i see Net 17-23 assigned to the various connected client.

My question is the same as first, does anyone succeeded to open a TLS connection to a remote broker? If yes, what is the correct configuration for usr_connect_config[]?

Thanks,

Rosario

Hello,

I am facing the same issue. does anyone got success?

Thank you.

Thank you RogerMonk , It worked for me.

Following this method very closely worked for me.

IF THIS IS NOT WORKING FOR YOU ON SOME SERVERS:
An issue I ran into which caused a lot of trouble was the hardcoded date and time. If your date is too far behind the current time, then you might get the SL_ESECDATEERROR, where the device is actually connecting to the server, then immediately disconnecting because it thinks the server certificate is invalid due to its date.

Hi,

How to generate certificate file for server?

Dinkar,

Dear ti:
I want to make it example connect to my own broker which is made by "mosquitto" not IBM.
And what I only change is the define of SERVICE_ADDRESS (my IP 192.166.53.17) But it eventually appeared

[NETAPP EVENT] IP acquired by the device
Host Driver Version: 1.0.1.11
Build Version 2.5.99.4.31.1.4.0.1.1.0.3.34
Device is configured in default state
Started SimpleLink Device: STA Mode
[WLAN EVENT] STA Connected to the AP: AAEON-IOT-GUEST , BSSID: 60:a4:4c:46:cb:d1
[NETAPP EVENT] IP acquired by the device

Device has connected to AAEON-IOT-GUEST
Device IP Address is 192.168.1.17

Version: Client LIB 1.4.0, Common LIB 1.5.0.
C: Alloc for 1 200246e4
C: Alloc for 1 200246e4

Broker connect fail for conn no. 1

Exiting the Application

How could I fix it?
Or any configuration I should verify?