In Impinj R700 firmware version 8.0, Impinj added the ability to load certificates and create certificate signing requests through the Impinj IoT device interface. This article documents securing the communication link between the reader's HTTPS Server and your applications using certificates from your own trusted Certificate Authority (CA) infrastructure. For detailed documentation of the Impinj IoT device interface, including the new certificate management features, please visit our developer portal at https://platform.impinj.com. This article assumes a basic understanding of cURL, certificate infrastructures, and REST APIs.
HTTPS is an encrypted communication protocol that provides the ability to secure digital communication between devices. The digital certificate chain is the mechanism of this trust, and it originates with a CA. CAs are a critical part of the internet. For example, you're using a CA every time you visit a website that starts with HTTPS. A CA is a trusted organization that verifies websites (and other entities) to know who you're communicating with online. This way, you don't unintentionally send your secure information to a remote hacker.
A root certificate is a public-key certificate identifying the root CA that forms the basis of an X.509-based public key infrastructure (PKI). A CA can issue multiple certificates in a tree structure. A root certificate is the top-most certificate of the tree, the private key used to "sign" other certificates. All certificates signed by the root certificate inherit the trustworthiness of the root certificate. Such a certificate is called an intermediate certificate or subordinate CA certificate. Certificates further down the tree also depend on the trustworthiness of the intermediates.
Looking at the SSL/TLS certificate details for https://developer.impinj.com, we can see that Sectigo Limited is the certificate authority. Because of the implicit trustworthiness of the Sectigo CA, you can be 100% confident that you're connecting to the official Impinj website:
Contrast this with the Impinj R700 reader's default certificate, which uses a self-signed certificate for the HTTP server's web UI and REST API.
Accessing the reader via HTTPS using curl will result in the following error:
Although self-signed certificates implement the same cryptographic key-pair architecture used in X.509 certificates, self-signed certificates are not generated by a trusted CA, like Sectigo. As a result, self-signed certificates are considered unsafe for public-facing web services.
To use certificates for trusted and encrypted communication with the Impinj R700, HTTPS must be enabled on the reader. Impinj R700 reader firmware version 8.0 enables HTTPS by default; however, if it was intentionally disabled with previous firmware settings, future upgrades will preserve that setting. Enable HTTPS either via the REST API or RSHELL using the following commands:
The Impinj R700 supports PKCS#12 and PEM formats for its server certificates. The following sections detail the process for generating each certificate type.
The PKCS#12, or PFX format, is a binary format for storing the server certificate, intermediate certificates, and private keys bundled into a single encrypted file. These files often have a .p12 or .pfx extension. Use this format when your CA generates the certificate and private key for you, and they both need to be uploaded to the reader. The following OpenSSL command creates a PFX file from a certificate (.crt) and private key (.key):
PEM or Privacy Enhanced Mail is a Base64 encoded DER certificate. Use this format when your CA expects a Certificate Signing Request (CSR) from your readers when generating certificates. The reader generates the CSR and private key using the following REST API method:
The method outputs the text of the CSR and keeps the private key on the reader, waiting to link it back to the signed certificate. The reader only preserves the three most recent CSR requests. Save the response text from the above method as a .csr file and submit it to your CA to start the certification generation process.
The following REST API method will automatically upload both PFX and PEM formatted certificates to your reader
Note: In the example above, the certificate used had no password.
- If you need a password, please add "--form 'password=<my password>'" replacing <my password> with the password you entered when creating the certificate.
- Adding a certificate with a password without passing in the password to the Certificate Management endpoint will error out with a 400 error code.
If the uploaded certificate is PEM formatted, the reader will look up the previously generated private key from the CSR process and match the certificate with the key. Otherwise, the reader expects both the certificate and private key bundled together in PFX format.
Linking Certificates to Services
The next step is to link the uploaded certificate to the reader's HTTPS service using the following REST API method:
This method links the new certificate to the reader's HTTPS service using the certificate's certId. The REST API and the web UI will use the linked HTTPS certificate when any client uses the HTTPS protocol. At this point, the reader is now providing secure authentication credentials. It is up to the client's configuration to properly utilize those security benefits.
Please refer to the following resources for more detailed information on this topic and other Impinj products:
- Impinj Support Portal – https://support.impinj.com
- Impinj Developer's Portal – https://platform.impinj.com