3

I have a module with a sim7080 chip. I want to use NBIoT to send data via mqtt to my server. But as a first step I wanted to start with http.

Sending HTTP Requests works pretty well. The problem occurs if using TLS.

OK
AT+CSSLCFG="convert",2,"mycert.crt"
OK
AT+SHSSL=1,"mycert.crt"
OK
AT+SHCONF="URL","https://test.test.eu"
OK
AT+SHCONF="BODYLEN",1024
OK
AT+SHCONF="HEADERLEN",350
OK
AT+SHCONN
ERROR

Is there a verbose mode to get more information what caused AT+SHCONN not to connect? HTTP is working fine. Maybe it is the format of the certificate? I downloaded the root ca of the website with Chrome as der certificate. Is this correct? May the windows \r\n be the problem?

I set header and bodylength to the value from the examples. Probably I have to change here later to the real size of the header and body (how to figure that out?)

Maybe so of you has a hint.

Best regards

emch2
  • 211
  • 2
  • 11

3 Answers3

2

@giovanni-campaner was exactly right about the modem clock preventing connection. If you don't care to check the expiration validity of the server cert you can also use

AT+CSSLCFG="ignorertctime",1,1

The next issue you'll run into is that some domains are hosted on machines that serve certificates for other domains. In that case you need to use Server Name Indication(SNI) to let the server know which certificate you're looking for.

AT+CSSLCFG="sni",1,"mydomain.com"

See my Gist for more details

baconcheese113
  • 843
  • 2
  • 13
  • 27
1

You must upload your certificate to the module first (one time) before calling AT+CSSLCFG="convert",2,"mycert.crt"

At least the .pem format works.

AT+CMEE=2 gives verbose errors, but I am not sure if you get more information on this error

The header and body length are max lengths, so those are not the cause of your issue.

Jeroen
  • 11
  • 1
1

The HTTP commands aren't verbose, you can first try the TCP/UDP commands, which give more detailed errors when failing.

When I tried the TCP/UDP commands, I got:

AT+CAOPEN=0,0,"TCP","httpbin.org",443
+CAOPEN: 0,24

Where code 24 means certificate expired.

Sometimes, the internal clock is wrong, then the certification fails because of the expiration date check.

First, query the clock: AT+CCLK? You may get: +CCLK: "80/01/06,10:34:34+00"

Which is totally wrong, as the year is 2080, and every certificate will be expired.

Set the clock using: AT+CCLK="22/06/26,22:28:00-12"

After this, there won't be code 24 anymore and it will connect.

Next steps would be sometimes sync the clock using NTP or GNSS info.

My sequence for HTTPS connection using TCP/UDP:

AT+CNTPCID=0
AT+CNTP="pool.ntp.org",-12,0,0
AT+CNTP

AT+CACID=0
AT+CSSLCFG="sslversion",0,3
AT+CASSLCFG=0,"SSL",1
AT+CASSLCFG=0,"CRINDEX",0
AT+CAOPEN=0,0,"TCP","httpbin.org",443,0

If there is an error, check your SIM chip.

Giovanni Campaner
  • 53
  • 1
  • 5
  • Thanks for the tip about setting the time! `AT+SHCONN` still returns ERROR even after getting `AT+CAOPEN` to return success...can you include more info about how to get an HTTPS request working? – baconcheese113 Nov 29 '22 at 21:23
  • Also it only works if ssl is disabled through `AT+CASSLCFG=0,ssl,0`, if I enable ssl then `AT+CAOPEN` responds with `+CAOPEN: 0,27` – baconcheese113 Nov 29 '22 at 21:58
  • I've faced the limitation that `AT+SHPARA` parameters and values can only have up to 64 characters in length, so ended switching to more flexible TCP/UDP commands. I suggest you to check an existing working implementation from the well known TinyGSM: https://github.com/vshymanskyy/TinyGSM/blob/3356c1d5c7bbde4a8440021b591453545ffccbde/src/TinyGsmClientSIM7080.h#L332 – Giovanni Campaner Nov 30 '22 at 22:51