EasyManua.ls Logo

Digi XBee3 - Transparent Mode and TLS; API Mode and TLS; Key Formats; Certificate Formats

Digi XBee3
172 pages
To Next Page IconTo Next Page
To Next Page IconTo Next Page
To Previous Page IconTo Previous Page
To Previous Page IconTo Previous Page
Loading...
Transport Layer Security (TLS) Transparent mode and TLS
Digi XBee3 Cellular LTE-M Global Smart Modem User Guide
101
Transparent mode and TLS
Transparent mode connections made when IP (IP Protocol) = 4 (TLS) are made using the configuration
specified by $0 (SSL/TLS Profile 0).
API mode and TLS
On the Transmit (TX) Request: IPv4 - 0x20 frame, when you specify protocol 4 (TLS), the profile
configuration specified by $0 (SSL/TLS Profile 0) is used to form the TLS connection. Tx Request with
TLS Profile - 0x23 lets you choose the IP setting for the serial data.
Key formats
The RSA PKCS#1 format is the only common format across XBee Cellular device variants. You can
identify a PKCS#1 key file by the presence of BEGIN RSA PRIVATE KEY in the file header.
Digi's implementation does not support encrypted keys, we use file system encryption to protect the
keys at rest in the system.
Certificate formats
The XBee3 Cellular LTE-M Global Smart Modem and the XBee Cellular 3G Global Embedded Modem do
not support X509 v3 certificates and extensions for the client certificate. However, v3 certificates
appear to be fine for CA certificates used in server authentication.
For SARA-R410 cellular components used in the XBee3 Cellular LTE-M Global Smart Modem, if the
server certificate has a Common Name (CN) that is greater than 31 characters the SSL connection
fails.
Certificate limitations
The XBee Smart Modem only supports certificate files that contain a single certificate in them. The
implications of this are:
n For client certificate files (for example when client authentication is required):
l Self signed certificates will work.
l Certificates signed by the root CA will work, because the root CA can be omitted per RFC
5246. The root certificate authority may be omitted from the chain, under the assumption
that the remote end must already possess it in order to validate it in any case.
l Certificate chains that include a intermediate CA are problematic. To work around this the
client's certificate chain has to be supplied to the server outside of the connection. In some
SSL implementations this can be done by adding the client certificate chain to the server's
ca_certs file.
n For server certificate files (when server authentication is required) this is not a problem unless
the client is expected to connect to multiple servers that are using different self signed
certificates or are using certificate chains that are signed by different root CA certificates. To
work around this you have to change the certificates before making the connection, or in the
case of API mode specify a different authentication profile.

Table of Contents

Related product manuals