When your device connects to a service, it needs to know that the service is the intended one. This tutorial explains how to establish that trust when you control both the device, acting as a TLS client, and the server. You create a Certificate Authority (CA), issue a server certificate, and install the CA's public certificate in the device.

Use this approach for a private device-to-service deployment. If browsers or third-party clients must trust your server without installing a private CA, plan for a publicly trusted certificate. A device that accepts inbound HTTPS connections has a different certificate provisioning task; see the SharkTrust example.

The trust relationship

The CA signs the server's certificate. The device trusts the CA because you provision its public certificate through a trusted process. During the TLS handshake, the device checks the server's certificate against that authority and the expected server name. The server proves that it holds the matching private key.

A device checks a server certificate against its installed CA and expected name.

Keep the CA private key separate from the device firmware and server. The server receives only its own private key and certificate chain. A device that only authenticates the server needs the CA public certificate, not the CA private key or a client identity certificate.

Plan for handshake memory

A small sensor message does not imply a small TLS handshake. The server sends certificates, and the device needs buffers and working memory to process them. Certificate size, chain length, enabled algorithms, and connection buffer settings all affect peak memory use.

Measure a full handshake with the certificate chain your service will actually send. Measure again after changing algorithms or certificates. Use build configuration to reduce optional code without removing trust checks.

Choose a certificate type

Elliptic Curve Cryptography (ECC) certificates can reduce public-key and signature size compared with RSA certificates at comparable security levels. Check that your server, device build, and any other clients support the chosen key and signature algorithms. The whole certificate chain matters, including intermediate CA certificates.

Illustration of certificate-size differences. Actual sizes depend on certificate contents and chain length.

For example, the TLS 1.2 suite TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 combines:

ECDHE: ephemeral elliptic curve key agreement that establishes shared secrets for the connection.
ECDSA: signatures used for certificate-based authentication.
ChaCha20: encryption of application data.
Poly1305: message authentication that detects changes to protected data.
SHA-256: a hash used by the TLS 1.2 suite.

These are separate jobs. An ECC certificate does not encrypt the application messages. For TLS 1.3, the cipher suite does not select the certificate type; key agreement and signature algorithms are negotiated separately. See cipher suites.

A dual-certificate server is an optional compatibility design. It is not required just because one client is a browser and another is a device. Choose certificate types and trust authorities based on the clients you must support.

Create and provision the certificates

Before you start, obtain:

A SharkSSL source or evaluation package with the certificate conversion tools and client examples.
A certificate creation tool. The RTL certificate management tool provides a web interface for creating a private CA and signing certificates.
A test server where you can install a certificate and its private key. Mako Server is one option; follow its configuration documentation for the version you use.

Run the conversion commands below in the directory containing your test certificates, with the SharkSSL tools available on your executable path. They illustrate file conversion, not CA creation or certificate issuance.

Create a CA and issue a server certificate

Create a private CA and protect its private key. Select algorithms compatible with your device build and server.
Create a separate server key and issue a server certificate signed by your CA. Set the intended domain name in the certificate's DNS Subject Alternative Name (SAN). A SAN lists the names the certificate identifies.
For a test where both programs run on the same computer, you can use localhost as the server name. A device on another computer needs a reachable server name and a certificate for that name.
Export the CA public certificate, server certificate, any required intermediate certificates, and server private key.

A CA signs separate server and optional device identity certificates.

If the certificate tool offers SharkSSL output, it can perform the binary conversion for you. Otherwise, use the command-line tools. Choose certificate lifetimes together with a renewal and trust-store update plan. A private CA gives you control of issuance and provisioning; it also makes you responsible for protecting the CA and maintaining it.

Install the server identity

Install the server certificate, matching private key, and required chain in the test server using its configuration interface. Restart or reload it as that server requires. Note its HTTPS listening port.

If the server itself uses SharkSSL binary identity data, convert the certificate and key with the tool supplied in your package:

# This generated identity contains private-key material. Protect the output.

SharkSslParseCert server.pem server.key > server-identity.h

Conversion does not make a certificate trusted. A browser will trust a private-CA server only if its trust store contains that CA, the server name matches, and its other certificate checks pass. Install a test CA only in a test environment you control.

Configure the SharkSSL client

Convert the CA's public certificate to a SharkSSL CA list:

# Embed the public trust anchor, not the CA private key, in the client.

SharkSSLParseCAList root-ca.pem > device-ca.h

Include the generated CA header in your client example.
Pass the generated CA-list array to SharkSsl_setCAList. Inspect the header for its array name rather than assuming a particular identifier.
Set the example's endpoint and port to your test server. Use the same expected domain name that you placed in the server certificate.
Preserve the application's trust-result checks. With selib, review seSec_handshake and accept only the result required by your trust policy. With the core API, use SharkSslCon_trusted with the expected name.
Configure SHARKSSL_CHECK_DATE and a correct clock if your product requires validity-date checks. Verify that those checks run in your build.
Build and run the example. Confirm both a successful TLS connection and an accepted server identity before exchanging application data.

Use example programs to select a client that matches your application protocol. For an SMQ client, the endpoint is an HTTPS URL, for example https://your-test-server:9443; the server must also provide the matching SMQ service.

If you need certificate-based client authentication, issue a unique client certificate and private key for each device, install that identity in the client, and configure the server to validate it. This is mutual TLS. Plan device-key provisioning and renewal separately from distributing the shared CA public certificate.

Verify the result and diagnose failures

Test rejection as well as acceptance. Connect with the wrong expected server name, then with an unrelated CA list. Neither connection should be accepted for application data. When date checking is enabled, also exercise an expired certificate.

Cannot connect

Check DNS resolution, routing, and the server's listening address and port. localhost refers to the machine running the client; on an embedded device it does not refer to your development computer.

TLS handshake or trust error

Confirm that the client is connecting to the TLS port, not a plain HTTP port. Check for a common TLS version and compatible cipher, key-agreement, and signature settings. For TLS 1.2 with an ECDSA-authenticated suite, the server needs a compatible ECDSA identity.

If the handshake completes but trust is rejected, check the installed CA list, server-supplied intermediate certificates, expected domain name, and validity dates. Correct the certificate or provisioning error before sending application data.