Anyone running with using SHA256 signed CA certificates on CC3100/CC3200 STA mode?

Hi Jonathan,


Can you please explain in detail issue you are facing.


Regards,
Aashish

Hi Aashish,

Yes. The short answer is I am playing around with the Exosite Cloud demo application and noticed they did not enable HTTPS sessions and were transmitting data in plaintext. I modified the connection code such that it is mirroring the SSL example in the CC3200SDK. I notice that whether I use any CA certificate in the certificate chain, the connection fails with SL_ESEC_ASN_SIG_CONFIRM_E (-155) which to me indicates that the certificate of the web server the client (the device) is connecting to could not be verified using the CA.

I then immediately fell back onto the SSL example application and noticed that the SSL example from the SDK worked fine, but the cert is a SHA1 signed cert. This is where one of my initial "what is different" questions and investigation paths that lead to creating the topic "has anyone gotten SHA256 working on CC3x00?"

The Exosite server is using a cert I have not worked with before. You can see the chain here ssl-tools.net/.../m2.exosite.com. I do not have another example immediately available to test whether the problem is SHA256, something specific to the application, or otherwise. I am investigating, but I was looking to the community to see if I could expedite the process. Also, see if the PEBKC... there is a possibility that I have made an error somewhere....

HW: I am using a QFN Launchpad with CC3200R1M2 silicon
SW: CC3200SDK1.1.0, ServicePack 1.0.0.10.0
Certificate loaded: Name: /cert/exositeca.der, URL: RapidSSLSHA256CA-G3.der

Code:
int SockIDorError = 0;
int LenorError = 0;

SlSockAddrIn_t Addr;
int AddrSize;
unsigned int uiIP;

//TODO: For testing
unsigned char ucMethod = SL_SO_SEC_METHOD_TLSV1_2; //Force TLSv1.2
unsigned int uiCipher = SL_SEC_MASK_TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256; //Force AES128-CBC+SHA256

LenorError = sl_NetAppDnsGetHostByName(EXOSITE_URL, strlen((const char *)EXOSITE_URL),
(unsigned long*)&uiIP, SL_AF_INET);

if(LenorError < 0)
{
Report("Device couldn't retrive the host name \n\r");
return 1;
}

//Change the DestinationIP endianity , to big endian
Addr.sin_addr.s_addr = sl_Htonl(uiIP);
Addr.sin_family = SL_AF_INET;
Addr.sin_port = sl_Htons(443);
AddrSize = sizeof(SlSockAddrIn_t);

SockIDorError = sl_Socket(SL_AF_INET,SL_SOCK_STREAM, SL_SEC_SOCKET);
if( SockIDorError < 0 )
{
Report("Error creating socket\n\r");
return 2;
}

// LenorError = sl_SetSockOpt(SockIDorError, SL_SOL_SOCKET, SL_SO_SECMETHOD, \
// &ucMethod, sizeof(ucMethod));
//
// if( LenorError < 0 )
// {
// Report("Error setting[1] cert method\n\r\n\r");
// return 3;
// }
//
//
// LenorError = sl_SetSockOpt(SockIDorError, SL_SOL_SOCKET, \
// SL_SO_SECURE_MASK, \
// (const char*)&uiCipher, \
// sizeof(uiCipher));
// if( LenorError < 0 )
// {
// Report("Error setting[2] cert cipher\n\r\n\r");
// return 4;
// }

LenorError = sl_SetSockOpt(SockIDorError, SL_SOL_SOCKET, \
SL_SO_SECURE_FILES_CA_FILE_NAME, \
EXOSITE_CA_CERT_FILE, \
strlen(EXOSITE_CA_CERT_FILE));
if( LenorError < 0 )
{
Report("Error setting[3] cert file\n\r\n\r");
return 5;
}

LenorError = sl_Connect(SockIDorError, ( SlSockAddr_t *)&Addr, AddrSize);
if( LenorError < 0 )
{
// error
Report("Error connecting to socket: (sl_Connect Error #%d)\n\r\n\r", LenorError);
if(LenorError == -8) //ENOSIGNVERIFY
{
//do nothing for now...
Report("Site could not be verified though CA certificate\n\r\n\r");
}
else
{
return 6;
}
}
curSocketID = SockIDorError;

//
//Set Timeout on Socket
//
struct SlTimeval_t timeVal;
timeVal.tv_sec = 2; // Seconds
timeVal.tv_usec = 0; // Microseconds. 10000 microseconds resolution
sl_SetSockOpt(SockIDorError, // Enable receive timeout
SL_SOL_SOCKET,
SL_SO_RCVTIMEO,
(_u8 *)&timeVal,
sizeof(timeVal));

return 0; //success, connection created

Hi again Aashish,

I think I may have solved my own issue indirectly. I am able to connect now, by using the root CA rather than any sub-ordinate CA's in the chain. Eg. using the Equifax Secure Certificate Authority.

ssl-tools.net/.../m2.exosite.com

Now, I still need to verify the cipher and method by forcing them... or is there another method of reading the cipher/method chosen?

Regards,
Jon

This doesn't make sense. Why do subordinate signed certificates within the chain not work?

Is there a way to load the entire certificate chain? If so, how do we observe the process of selection and verification from the host MCU software?

Hi Jonathan,


We are looking into this and will get back to ASAP.


Regards,
Aashish

I am having same problem with SHA256 that sl_connect90 returns error code -155.

I was able to reproduce what Jon had done to connect to exosite.com, however, I couldn't connect to dev.traceablelive.com by the same way that used Root CA, and error code returned (-208).

Hi Alon,

Thanks fo reply. I double checked that the service pack was 1.0.0.10.0, and I also tried Root CA.

Looking at the chain on https://ssl-tools.net/webservers/dev.traceablelive.com. There are SHA384 certificates in the chain with no lower alternatives... I suspect that there may not be support for SHA384 and since SHA1 certificates are being phased out, the server (and client possibly) may be trying negotiate a higher security certificate than SHA1.

Also, it is not clear if CC3x00 supports SHA384 or SHA512... I am wondering if this is something not supported. Cannot check because the DTHE module on the CC3200 is not documented in the TRM and I have actively tried to check what algorithms are supported, but from looking at the #defines for the crypto supported... I would guess this is not in the list.

Just my speculation; I could be wrong -- and I hope I am.

Regards,

Jon

Alon,

Thanks for the confirmation regarding the subordinate certificates in the certificate signature chain from the root CA. That makes sense, but the problem is how to verify which certificate is being used. I have a requirement to NOT use SHA1 and to test and verify SHA256 is used.

Regards,
Jon

Thanks, Jon.
I looked at the chain, and noticed SHA384. However, the Root CA uses sha1WithRSAEncryption, and it didn't work.

Hi Leo,

Have you tried forcing the cipher to use SHA1 as a test? I am curious if you force the connection if it works:

unsigned int uiCipher = <select one below>;

#define SL_SEC_MASK_TLS_RSA_WITH_AES_256_CBC_SHA (1 << 2)
#define SL_SEC_MASK_TLS_DHE_RSA_WITH_AES_256_CBC_SHA (1 << 3)
#define SL_SEC_MASK_TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (1 << 4)
#define SL_SEC_MASK_TLS_ECDHE_RSA_WITH_RC4_128_SHA (1 << 5)

sl_SetSockOpt(SockIDorError, SL_SOL_SOCKET, SL_SO_SECURE_MASK, (const char*)&uiCipher, sizeof(uiCipher));

Try this with these 4 and let me know if it connects with any of them? I have a hunch that it will succeed with one or all of the SHA1, if and only if SHA1 is forced.

Regards,
Jon

Jon,

I tried all of them (all sha1 and sha256) with combination of method, either returning -208 or -155 code.

There seem to be multiple people having these problems I see...

e2e.ti.com/.../423617
e2e.ti.com/.../424924

Hi Jonathan,

We've found that some servers using SHA2 are failing the connection since we don't publish that we support SHA2 in the SSL creation.
We are working to fix it.

Are you able to continue working with SHA1 for now till we will release the fix for this issue?


Thanks,
Alon

Hi Alon,

Is TI planning to support subordinate certificate?

CA certificate has 3 years life.

Do we need to update  remotely all our units every three years ?

Thanks

Michael

Hi Alon,

We use a wild card certificate  *.company.com

Is any possible problem with using wild card CA certificate?

Thanks

Michael

I have a similar problem. I am trying to authenticate a site hosted by Microsoft azurewebsites.net which uses the Baltimore CyberTrust Root certificate. This certificate uses SHA2. I can establish a secure ssl connection to the site but I always get a -456 error when I try to authenticate. Do I need to wait for a new service pack or switch to a server authenticated by an SHA1 certificate?

Apologies, my problem was caused by a bad path to the root CA file, not by the file itself.