HTTPS support on Pico!

I see the 0x6d00 error is a public key mismatch. I didn't see the other error code, but I would guess it's related.

line #117 in libs/crypto/mbedtls/include/mbedtls/ssl.­h

#define MBEDTLS_ERR_SSL_PK_TYPE_MISMATCH -0x6D00 /**< Public key type mismatch (eg, asked for RSA key exchange and presented EC key) */

Did you sort this out? On the other post you made a few hours before you mentioned another error code.

Maybe you could keep the discussion to one thread, so we're not answering questions you've already answered?

Also - maybe we can keep track of the common error codes people are getting, so I can make sure they're not reported as numbers but as actual text?

• 0x6D00 - public key type mismatch
  
• 0x7200 - n invalid SSL record was received.
  
  

Anything else?

Yeah sorry about that Gordon. I am using the Pico + ESP8266 with pretty much the same code. I am actually working on doing a GET request. 0x256a and 0x7200 is where I am at right now. I did everything as stated in that HTTPS Authorized Certs with Node.js. I've tried changing a few of the codes around. In the Espruino I put the key to client1-key.pem, cert to client1-crt.pem, and ca to ca-crt.pem.

Made everything again and am getting the 0x6d00 with the 0x256a now. What does the public key type mismatch mean exactly? Online it says that the client key is not matching the server key (google)? Even tried running your original codes and got the same.....

I just tested, and the example code I posted works (although uploading it is sometimes a pain). I also generated new keys using the exact code below, and that works too:

// Steps taken from: 
// https://engineering.circle.com/https-aut­horized-certs-with-node-js/

wget https://raw.githubusercontent.com/anders­94/https-authorized-clients/master/keys/­ca.cnf  
openssl req -new -x509 -days 9999 -config ca.cnf -keyout ca-key.pem -out ca-crt.pem  

# Create a client key
openssl genrsa -out client1-key.pem 4096  
# get a config file
wget https://raw.githubusercontent.com/anders­94/https-authorized-clients/master/keys/­client1.cnf  
# Signing request
openssl req -new -config client1.cnf -key client1-key.pem -out client1-csr.pem  
# Sign
openssl x509 -req -extfile client1.cnf -days 999 -passin "pass:password" -in client1-csr.pem -CA ca-crt.pem -CAkey ca-key.pem -CAcreateserial -out client1-crt.pem  
# Verify
openssl verify -CAfile ca-crt.pem client1-crt.pem  

# Now get our keys into a format that can be used by Espruino.
# The following commands just strip off the first and last lines
# and remove all the carriage returns - this could be done by hand
# if needed.

sed '1d;$d' client1-key.pem | tr -d '\n'
# Copy, and paste into the quotes for `okey = fwrite( atob("") );`

sed '1d;$d' client1-crt.pem | tr -d '\n'
# Copy, and paste into the quotes for `ocert = fwrite( atob("") );`

sed '1d;$d' ca-crt.pem | tr -d '\n'
# Copy, and paste into the quotes for `oca = fwrite( atob("") );`

I've updated the tutorial now although it's not on the main Espruino site yet.

Has someone got a better way of making the keys than this? In fact, do you even need ca and cert?

That's interesting...... I'm using the ESP8266WiFi module. Do I need to upgrade the ESP8266 and run the ESP8266WiFi_0v25 module?

I haven't tested with the old one - it should still work though. As I recall there weren't huge changes between the two modules - definitely not as far as data handling is concerned.

Having said that, the new one does seem to be more reliable at keeping the network connection up, so it might be worth upgrading. It's not that bad now you can do it through the Pico, it's just a faff to install the esptool software

Ugh this is getting frustrating. I updated the esp. I copy and pasted your code from GitHub and only changed the wifi settings.

1v84.351 Copyright 2016 G.Williams
>echo(0);
=undefined 
Saving key 
Saving cert 
Saving ca 
Done!
>save()
=undefined 
Erasing Flash..... 
Writing......................... 
Compressed 81600 bytes to 22816 Checking... 
Done! 
Running onInit()...
>
=undefined
=undefined 
Connecting to WiFi
192.168.10.2 
Connecting to Google 
Connecting with TLS... 
Loading the CA root certificate... 
Loading the Client certificate... 
Loading the Client Key... 
Performing the SSL/TLS handshake... 
ERROR: Failed! mbedtls_ssl_handshake returned -0x256a 
ERROR: Failed! mbedtls_ssl_handshake returned -0x6d00
> Disconnected
>

Just in case anyone is interested on secure webSockets I have a rough implementation on GitHub (wss.js) based on the examples in this thread and the current ws module. It works with my server, but I would like to make some more tests and do the server part before asking for a pull request.

By the way, I used a new module, wss.js, instead of modifying the current ws.js file since TLS is not available on all Espruino boards. But I can accept sugestions.

I wonder if this is a USA - Google thing? I have tried 3 different Espruinos Picos and ESP8266. Made a new form and even tried posting to yours with the exact same code. At this point I have no idea what to try next?? Any ideas?

I have been playing around with Node.js and I came across this..... https://nodejs.org/api/https.html

key: Private key to use for SSL. Default null.
passphrase: A string of passphrase for the private key or pfx. Default null.
cert: Public x509 certificate to use. Default null.
ca: A string, Buffer or array of strings or Buffers of trusted certificates in PEM format. If this is omitted several well known "root" CAs will be used, like VeriSign. These are used to authorize connections.

I built a client app.js and have been using both POST and GET to send information into a Google Form or direct to spreadsheet with these all left at default. So to answer your question it appears that the only thing needed is the CA.

Hmm. I guess it could well be a difference with google USA... Maybe try and set up an HTTPS server yourself and see if you can post. It'd be a start.

@Gordon I'll do that right now. In the mean time is it possible to allow the http request on the Espruino to accept null for the key and cert?

I'll have a look at it. To be honest it looks a bit broken at the minute - like specifying any options at all (but not all 3) would cause it to error.

Actually, just to totally rule out some things, you could try compiling Espruino to run natively on your computer, and then try HTTPS on that. I'm not sure if a MacOS native compile works, but it'll work on Linux, or if you have a Raspberry Pi then you could try that?

I have the Linux running now. I'm having a little trouble pasting this code in here. Did you have any documentation on this or any recommendations for me. Even trying to just pasting the individual ca code isn't going in very well.......

Update see the C code. I'll Figure it out......Thanks

Connecting with TLS...
Loading the CA root certificate...
ERROR: HTTPS init failed! mbedtls_x509_crt_parse of 'ca': Invalid format

ERROR: Unable to create socket

This is what I am getting on Linux right now.

Victory!

You probably just want to put the code in as a JS file, and run ./espruino mycode.js.

Victory as in working on Linux, or working on everything?

Just on linux. Definitely a no-go for the Pico.
Also just curious if this will be available on the WIZ550io?

Hmm, interesting - and you were using the 0.25 firmware on the ESP8266 when it wasn't working?

And yes, the way HTTPS is done it'll work on WIZ550io, CC3000, GSM, and anything else that comes along. I have only personally tried it on the WIZ550io though.

Well I actually got a bunch of WIZ550io and what do you know. I can't even get them on the internet. Appears to be a similar problem to this one. I have your first run of Picos. Maybe they are defective? I might just order some new ones......

Oh, so you get IP:0? Can you use setIP({ip:"192.168.1.2"}) and then getIP and see if you can read it back?

It could just be a connection issue - I reproduced exactly the same problem when I disconnected the CS pin.

There shouldn't be a problem with the Picos - the first run are absolutely fine, they just don't have a fuse on them so you have to be careful not to short the power rails out or the diode fries :)