I’m tryng to connect an rabbit RCM67xx as a client to a web server to send a message on the telegram messages platform.
I’m having problem with certficate (i think) those in the folder Samples/tctip/sample_certs, may be expired.
I want to to open a web link for example https://api.telegram.org/botXXXXXX/sendMessage passing in GET or POST a couple of variables (chatid and text)
Is there a way to connect in https ignoring the local certificate of the CA?
I think that certificate expiration could be a problem anyway in the future as i can’t update on the selled units.
I have found settings in the httpc_set_tls function parameter SSL_F_PPER_CERT_OK to accept all certificate, but not work (also with www.google.com)
1 Like
There was an issue reported with the certificates, you should add the fix from github and verify you are running the latest DC10.72D
https://github.com/digidotcom/DCRabbit_10/issues/16
First off, make sure you’re running Dynamic C 10.72D as advised by Campbell in another answer. The original Dynamic C 10.72 release doesn’t support TLS 1.2, which is required by almost all web servers now.
What exactly did you use in the httpc_set_tls() function? SSL_F_PEER_CERT_OK on its own, or (SSL_F_REQUIRE_CERT | SSL_F_PEER_CERT_OK)?
If you uncomment the define for SSL_CERT_VERBOSE, does the sample print out useful information on why it rejected the connection? Is it possible this is something other than a certificate failure?
You need to take a look at the certificate used on https://api.telegram.org (by using a web browser), and find the root certificate that signed it. Configure the HTTPS_CLIENT sample with that root certificate and you should be able to make connections.
Take a look at the Remote Program Update library and samples for methods of doing remote firmware updates for long-term support of your product. You could also use the HTTP client code to download new root certificates as necessary. You could configure a small FAT file system on the serial flash of the RCM67xx and store root certificates there.
Dear
Many thanks for reply.
I confirm I’m using 10.72D version of DC.
i have applyed the patch suggest from Campbell and now the library report a warning like:
line 1119 : WARNING X509.LIB : Demotion of value may lose digits.
may be i need to redefine the len variable?
I’m using only SSL_F_PEER_CERT_OK
i have also defined the SSL_CERT_VERBOSE
i have downloaded the pem chain certificate of the website api.telegram.org and save it in the right folder.
- the application seems to load right the certificate:
SSL_new_cert: cert=0020EBA4 addr=0001E24A type=2 append=0
crypto_public_key_import() returns 000AE9C0
SSL_new_cert: OK
Parsing https://api.telegram.org/bot12xxxxxxxxxxxx
scheme : 1 : https
userinfo : 6 :
username : 6 :
password : 6 :
hostname : 7 : api.telegram.org
port : : 0
path : 24 : /bot12xxxxxxxxxxxx
filename : 25 : bot12xxxxxxxxxxxx
query : 74 :
fragment : 74 :
HTTPC: using scheme ‘https’
httpc_get: opening socket
HTTPC: Resolving api.telegram.org
HTTPC: Opening IP=959AA7DC port=443 iface=0xff
HTTPC: Socket connected!
sock_secure: as client
sock_secure: setting trusted 0020EBA4
sock_secure: OK, returning secure=AC02
_sock_tls_handler: calling sock_abort()
HTTPC: unexpected error (rem=5), aborting connection
sock_unsecure: unsecuring=AC02
SSL_free_cert: cert=0020EB82 format=0
SSL_free_cert: cert=0020EB92 format=0
HTTPC: unexpected error (rem=5), aborting connection
Non-blocking open took 2534ms, and 15496 iterations
error -411 calling httpc_get_url()
I will try to investigate
Perhaps we need to schedule a 10.72E release. There are some additional patches you may want to apply, and if you’re comfortable using Git for revision control, I recommend following the directions on the GitHub repository for linking the repository to your install so you can easily update to the latest development branch.
Here are commits you should consider:
This one allows 4096-bit keys, which I suspect could be causing your problem: https://github.com/digidotcom/DCRabbit_10/commit/b5b4d0fa2ecdb1d18fe67ef44ba34ee9ed84c2a5
And this one addresses the compiler warning in X509.LIB:
https://github.com/digidotcom/DCRabbit_10/commit/5f5bb175ce844b0e64fb56562a7cf9fc0a046feb
Instead of SSL_CERT_VERBOSE, you could try uncommenting X509_CHAIN_VERBOSE and SSL_SOCK_VERBOSE to see if you get additional information on that “unexpected error”. The “rem=5” line indicates how many redirects remain, and implies to me that there weren’t any redirects.
If you’re comfortable using the debugger, you could enable debugging in the HTTPC.LIB and set a breakpoint on that “unexpected error” printf(), then step through the code to see how you ended up there, and maybe get some visibility into what some variables were in calling functions.
Please let me know if the new commits resolve your issues and I’ll ask Digi to schedule a 10.72E release.
Dear
I have tryed starting from a fresh sample HTTPS_CLIENT_NB.C
I have applyed the patch suggested in before message.
I have made all of these belove:
- support for 4096 cert
- download from browser cert chain and saved into specifica folder, addedd in the software (all cert auth are ok when loaded)
- i have set SSL_F_PPER_CERT_OK parameter.
I have tryed different website:
www.ica-net.it (our website and works fine)
www.google.com (works fine)
www.cisco.com (not works)
www.lastampa.it (not works)
also the web site with the iot application, that use a let’sencrypt certificate (not works)
for all above I have also downloaded the cert chain and saved into cert folder (and imported in the firmware, of course)
I have tryed, and i’m trying to debug the library, but it’s not simple.
I thinks there is a issue in the library.
I will wait for new E release of DC, I hope the release will be available as soon (few days).
If you have other test to send me i can try.
If the new release became so far, i can valutate to pay a support to solve this issue, did you have an idea on how much could cost for specific support?
Thanks
Thank you for the detailed testing. I was able to reproduce the failure by testing with https://www.cisco.com/. Please change the definition of TLS_MAX_TCP_BUFFER_LENGTH in SSL_DEFS.LIB to:
#define TLS_MAX_TCP_BUFFER_LENGTH (16 * 1024 + 256)
The previous value was 16 bytes too small to negotiate the TLS handshake with www.cisco.com. This change matches a recent RFC related to TLS 1.3 (which we don’t support yet), but seems to establish a limited amount of overhead (256 bytes) for the 16KB record size limit.
Please test and reply to this message to let me know if it solves your problem. Please don’t create another answer to the forum post because I only see notifications of comments on my answers.
GREAT !
now it works fine! with cisco.
I have problem with telegram and other, but that issue is not more important, because we have implemented a IoT server connected to RCM and we can send message from IoT server.
this solution is more simple to develope and adaptable to customer feature request.
I will wait the new release of DC to make mote test
You can close the ticket, if i can suggest to implement a sample with telegram bot, i think that is interesting for a lot of developer.
Marco Piai
p.s. I hope RCM6760 will be available for a long time…