Hi, has anyone got the HTTPS demo for the 9215 working?

I am trying to get the ‘HTTPS Server Sample using the AWS’ example to serve up web pages, but despite following the instructions in the readme, I can’t get any browser to serve up web content from the device.

Any suggestions welcome!

Hello David

I have run it on any number of (different) devices. Remember that certificates must be loaded on both the device and the browser. You must have the FLASH file system up to load the certificates into the FLASH file system. Are you using the certificates supplied with the application or your own?


I used FTP to load the files in the /keys directory into the /FLASH0 directory.

I added cacert.pem to the Trusted Root Certificate Authorities and httpsClnt.pfx to the personal certificate window in IE & chrome (password “Digi https key”). I notice the certificate (httpsClnt.pfx) expired 05/11/2011, is this the problem?

How do you create your own certificates, or do you have to pay a lot of money to the likes of verisign etc…?

Basically our customers are asking more frequently for HTTPS on our kit and I am trying to work out what we need to do, but getting nowhere fast!

Best regards,


There is an updated document, available through package manager that explains creating and using SSL certificates using the openssl utility. I believe the document also contains a URL for installing openssl. Openssl is an open source product.  There may be a copy in the Documentation directory and one in the Documentation\White Papers directory. You want one dated Dec 2012 or later. Also I'd recommend looking at a copy of Network Security with OpenSSL by Viega, Messier and Chandra. Published by O'Reilly.


I got the new pdf and I have the book on order, however the pdf did not mention how to create the certificate revocation list file… so I commented out #define TEST_USING_CRL.

/* These defines specify the file name and full path name of the /
client certificate file. Server can add this to peer revocation /
list */
#define CLNT_REV_CERTICATE_FILE “clntrevcert.pem”

I copied/pasted and renamed ‘clntcert.pem’ to ‘clntrevcert.pem’ then uploaded it. Was this the right thing to do?

So far I can see the browser makes contact with the Digi device, I get prompted to pick a certificate, then nothing much happens, other that chrome giving up after a while…

Looking with Wireshark I can see a Server Hello & Server Hello Done, but it seems the Client Hello is met with a FIN, PSH, ACK response…

I guess I could have put the wrong info into the openSSL tool for the client?

Looking at the sample certificate ‘httpsClnt.pfx’ the CN is ‘Nassl Client’ not an IP address, perhaps this is where I am going wrong.

Also I notice file.c in the sample app checks for APP_FILE_SYSTEM being defined, which appears not to be the case… I will try defining this as see what happens…


Hello David

The 'httpsClnt.pfx'  is a MicroSoft format thing, compatible (I believe) only compatible with IE. I think the other browser you just load a regular certificate (created with openSSL) into the browser.


It appears all of the major browsers require the *.pfx client certificate.
Chrome uses the same certificate dialogue/database as IE.

While capturing with Wireshark I discovered that firefox uses TLS1.0 (and works), IE by default used TLS1.1, I could see alerts issued by the Digi module and IE dropping back to TLS1.0, however the Digi module closes the connection.

Disabling TLS1.1 & TLS1.2 does allow IE to get data from the Digi, however it takes the Digi about 60 seconds to reply.

So, I have 2 of the major browsers covered. I cant find a way to force the TLS version on Chrome and Opera, I can see the start with TLS1.2 and drop down to TLS1.0, but I think the get bored of waiting for the digi to reply and kill the connection. (Both of these browsers are using the blink engine, so I guess that is why I am having trouble with them - I will investigate if I can alter the timeout).

Interestingly Safari for windows works, it takes about 30 seconds to get a reply from the Digi, however Safari for windows is not being developed any more, so this could be why it starts off using TLS1.0.

Any suggestions in the mean time welcome!