ERROR: SSL/TLS Error: Unable to connect (-330)

[chrispawlak9]

Posted on May 02, 2016 at 19:56

With a SPW01SA I'm able to connect to a server using anonymous negotiation, but I often get the following error trying to open a socket before it opens successfully:

ERROR: SSL/TLS Error: Unable to connect (-330)Questions:Exactly what does (-330) indicate?

1. Does it makes sense that I tend to see the error more often when there is a lot of traffic on the server?
2.  A co-worker thought that the problem may be that I don't have the wi-fi authenticating the server's certificate. If that was the problem, I shouldn't ever be able to open a socket to the server using anonymous negotiation, right?
3. I tried one-way authentication, but I get this error: ''ERROR: SSL/TLS Error: Unable to connect (-322).'' Could that be because I'm specifying the wrong domain in the command AT+S.TLSDOMAIN=f_domain,<server domain>? The certificate was created from godaddy so I used godaddy.com (and ca.godaddy.com, certs.godaddy.com, etc) in place of <server domain>, but I always get the error.

Note: Before setting the <server domain> I do clear out the certificate information with AT+S.TLSCERT2 and set the time (in seconds) and load the certificate (in PEM format). When I send AT+S.TLSCERT=f_content,0 I get this response# TLS loaded CERTs:#  CA Cert: YES#  Client Cert: NO#  Client Key: NO#  Domain Name: YES - godaddy.com

[chrispawlak9]

Posted on May 03, 2016 at 00:15

So, I'm guessing <server domain>, as in AT+S.TLSDOMAIN=f_domain,<server domain>, does not refer to the domain name of the Certification Authority as I was lead to believe by UM1695, which has this:

<ca domain name>: domain name of the Certification AuthorityI'm guessing it actually refers to the domain name of the server to which you are opening a port to.  And that name should match the one listed in the CA certificate. Well, either way I get the same error.

[gaibotti.adriano]

Posted on May 03, 2016 at 13:14

Hi,

The error -330 is a 

VERIFY_SIGN_ERROR. It is strange that this error comes during an anonimous authentication. Are you sure that there are no certificates loaded into flash during the authentication? Try to clean the flash using AT+S.TLSCERT2=clean,all and tell us if the problem persists.

In one-way authentication, error code -322 means DOMAIN_NAME_MISMATCH. As you stated there is an error in the documentation. With the command AT+S.TLSDOMAIN you have to specify the server domain, which refers to the Common Name (CN) field inside the server certificate. Usually this field is the URL of the server, but the best thing to do is to check directly inside the server certificate this field.Let us know if these comments solve your issues!

[chrispawlak9]

Posted on May 03, 2016 at 19:48

I tried 

AT+S.TLSCERT2=clean,all just now and it seemed(?) to help, but the error still occurs. Once it happened 7 times in a row (with SOCKON requests spaced 10 seconds apart) before being able to connect. Is it possible for a server to require one-way authentication, with the error being the result of NOT using one-way authentication? I figured one-way authentication or anonymous negotiation was up to the client.

[gaibotti.adriano]

Posted on May 04, 2016 at 11:39

Actually the server is in charge of establish the authentication type choice. It is strange that sometimes the same server requires anonymous and sometimes one-way. But the fact that the error that you have is a VERIFY_SIGN_ERROR makes me lean toward the hypothesis that the server sends to your client its certificate but the client, since it hasn't the CA, is not able to verify the signature.

Do you still have the DOMAIN_NAME_MISMATCH error in one-way authentication?

[chrispawlak9]

Posted on August 23, 2016 at 23:45

I had to abandon work on this issue earlier, but now I'm back on it. I'm doing one-way authentication, and I don't get the DOMAIN_NAME_MISMATCH error anymore, but I still get the VERIFY_SIGN_ERROR. Here are some questions I have:

1) Does VERIFY_SIGN_ERROR pertain only to the signature of the server certificate? Or could it also pertain to the root CA certificate?

2) With regards to one-way authentication, AN4683 (section 2.4.2) states, ''The maximum allowed size for files uploaded to module is approximately 1.3 KB.'' The root CA certificate is 1.47 KB. Could that be causing the VERIFY_SIGN_ERROR? If the root CA certificate is too big, I would have expected the error to be ''ERROR: Unable to load CA certificate''. But that's not the error I'm seeing. We are using GoDaddy's certificate, so I don't think we can get a smaller version of it.

3) I verified the root CA certificate is in PEM format. Does the server certificate need to be in PEM format, too?

4) I read that problems can occur depending on whether certificates contain CR/LF bytes or just LF bytes. What does the SPW01SA support? I found that the root CA certificate does contain CR/LF bytes but I haven't been able to check the server certificate yet.

5) Is there a document that lists and explains all the error numbers associated with ''ERROR: SSL/TLS Error: Unable to connect''? (For example, -330 is for VERIFY_SIGN_ERROR, -322 is for DOMAIN_NAME_MISMATCH , etc.)

[gaibotti.adriano]

Posted on August 25, 2016 at 15:16

Hi,

I need to make some tests in order to understand what is the problem you are facing with. Is it possible to replicate your experiments on my side (i.e. provide to me the server address and the needed certificates)? Regarding your questions:1. VERIFY_SIGN_ERROR can come at any level of the certificate chain (and I think that you have this error when trying to verify the root CA);2. It is possible that the problem is the certificate size, but I need to make tests in order to check if it is the real issue.3. It doesn't matter about the file type of the certificates4. Also the CR-LF vs LF is not a problem.5. In order to look at error codes you can refer to the documentation of cyassl: https://www.wolfssl.com/documentation/CyaSSL-Manual.pdf

[chrispawlak9]

Posted on August 25, 2016 at 20:12

Thank you for your answers! I attached the root CA certificate. The server address is www.applusobd.com. This is what I send to the module:

AT+S.TLSCERT2=clean,all<CR>AT+S.SETTIME=1472147815<CR>AT+S.TLSCERT=f_ca,1472<CR><the contents of the attached certificate>AT+S.TLSDOMAIN=f_domain,www.applusobd.com<CR>AT+S.SOCKON=www.applusobd.com,443,s,indThen I get the VERIFY_SIGN_ERROR.By the way, I'm running into another issue. Sometimes when I send the SETTIME command, the module seems to lock up and then reset. It usually accepts the command when I send it a second time.

[chrispawlak9]

Posted on August 25, 2016 at 20:13

Thank you for your answers! I attached the root CA certificate. The server address is www.applusobd.com. This is what I send to the module:

AT+S.TLSCERT2=clean,all<CR> AT+S.SETTIME=1472147815<CR> AT+S.TLSCERT=f_ca,1472<CR><the contents of the attached certificate> AT+S.TLSDOMAIN=f_domain,www.applusobd.com<CR> AT+S.SOCKON=www.applusobd.com,443,s,ind Then I get the VERIFY_SIGN_ERROR. By the way, I'm running into another issue. Sometimes when I send the SETTIME command, the module seems to lock up and then reset. It usually accepts the command when I send it a second time. ________________ Attachments : _4_GoDADDYCA.cer.txt : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I1KU&d=%2Fa%2F0X0000000bmy%2FQ269QeXSAMs7wEKAx.Hc6nKDRe7S2Zy5ISrtFXQJukg&asPdf=false

[chrispawlak9]

Posted on August 26, 2016 at 06:35

I should also mention that I was able connect to different server (data.smogdaddy.com) through a secure socket even though I didn't have a certificate loaded. I sent:

AT+S.TLSCERT2=clean,all<CR>AT+S.SOCKON=data.smogdaddy.com,443,s,indSometimes that would cause a VERIFY_SIGN_ERROR, but if I sent the SOCKON command again, it would eventually open the socket. I even got the WIND:55 messages with ''ENC'' (encoded), suggesting the socket really was secure. Do you have any idea why that worked without a certificate loaded for the data.smogdaddy.com server but not the www.applusobd.com server?