Secure a Connection with TLS

In this tutorial you will build a small internal public key infrastructure (PKI) in the Certificate Manager, issue a server certificate for a protocol endpoint, and turn on TLS so the connection is encrypted and authenticated. By the end you will have a self-signed root CA, an intermediate CA, a server certificate with Subject Alternative Names, and a protocol endpoint that loads that certificate and negotiates TLS.

What you'll need

• Access to the control plane UI with permission to open the Certificate Manager app.
• A protocol controller and endpoint already configured, for example a Dnp3MasterTlsEndpoint, OpcUaEndpoint, MqttBrokerEndpoint, or HttpClientEndpoint. If you have not set one up yet, follow the device configuration walkthrough first.
• The hostnames and IP addresses the endpoint will be reached by, so you can enter them as Subject Alternative Names (for example server.local and 192.168.1.10).
• About 10 minutes.

Step 1: Open the Certificate Manager

1. From the control plane UI, open the Certificate Manager app.
2. Note the tabs across the top: CA Hierarchy, Server, Client, Peer, and Revocation List. You will work left to right: first the CA, then the leaf certificate.

Expected result: the Certificate Manager opens with the tabbed layout. If you already have certificates, they appear as rows with color-coded status badges.

Step 2: Create a root CA

A root CA is the self-signed trust anchor that ultimately vouches for every certificate you issue.

1. Select the CA Hierarchy tab.
2. Click New Certificate.
3. Set CertificateType to RootCA.
4. Leave SigningCA empty, since a root signs itself.
5. Fill in the subject fields: SubjectCommonName (for example ControlBird Root), SubjectOrganization, and SubjectCountry.
6. Set KeyAlgorithm to RSA-4096, recommended for long-lived root CAs.
7. Set a long ValidityDays for the root, such as 3650 (10 years).
8. Submit to generate the self-signed root.

Name:                Root CA
CertificateType:     RootCA
KeyAlgorithm:        RSA-4096
SubjectCommonName:   ControlBird Root
SubjectOrganization: My Org
ValidityDays:        3650
SigningCA:           (none)

Expected result: a new row appears under CA Hierarchy with a green Valid badge. The Thumbprint and SerialNumber fields are populated from the generated certificate.

Step 3: Create an intermediate CA

An intermediate CA signs your leaf certificates on behalf of the root, so the root's private key can stay offline. This step is optional but recommended for anything beyond a quick test.

1. Still on the CA Hierarchy tab, click New Certificate.
2. Set CertificateType to IntermediateCA.
3. Set SigningCA to the Root CA you just created.
4. Fill in the subject fields and choose a KeyAlgorithm.
5. Submit.

Expected result: the intermediate appears with a Valid badge, and its CertificateChain is built automatically up to the root.

Step 4: Issue a server certificate

This is the leaf certificate the protocol endpoint will present. Get the Subject Alternative Names right here: modern TLS clients validate the hostname against the SAN list, not the Common Name.

1. Switch to the Server tab.
2. Click New Certificate.
3. Set CertificateType to Server.
4. Set SigningCA to the Intermediate CA (or the root if you skipped Step 3).
5. Set SubjectCommonName to the primary hostname, for example server.local.
6. Enter SubjectAltNames as a single comma-separated string, each entry prefixed with DNS: or IP:, for example DNS:server.local,DNS:server.example.com,IP:192.168.1.10.
7. Choose a KeyAlgorithm (the default RSA-2048 is fine for leaf certificates).
8. Set ValidityDays, such as 365.
9. Submit.

Name:             server.local
CertificateType:  Server
SubjectCommonName: server.local
SubjectAltNames:  DNS:server.local,DNS:server.example.com,IP:192.168.1.10
SigningCA:        Intermediate CA
ValidityDays:     365

Expected result: a server certificate appears with a green Valid badge under the Server tab, ready to attach to an endpoint.

Step 5: Enable TLS on the protocol endpoint

Protocol endpoints enable TLS through two fields: a TlsEnabled boolean and a Certificate entity reference.

1. Open the endpoint entity you want to secure, for example Dnp3MasterTlsEndpoint, OpcUaEndpoint, MqttBrokerEndpoint, or HttpClientEndpoint.
2. Set TlsEnabled to true.
3. Point the Certificate field at the server certificate you created in Step 4.
4. Save the endpoint.

Expected result: with TLS enabled, the protocol service loads the referenced certificate (its certificate data, private key, and chain) and brings up the encrypted connection. No manual file handling is required.

Step 6: Verify and maintain

1. Back in the Certificate Manager, confirm the server certificate still shows a green Valid badge. The status updates automatically, moving to Expiring (yellow) once the certificate falls within the controller's ExpiryWarningDays window (default 30).
2. When a certificate approaches expiry, select it and click Regenerate to extend its validity. The existing subject, key algorithm, and signing CA are retained, though a fresh key and certificate are always generated.
3. To pull a certificate out of service, select it and click Revoke. Its status becomes Revoked and the CRL regenerates automatically.

Expected result: the badge colors give you an at-a-glance view of certificate health: Pending (purple), Valid (green), Expiring (yellow), Expired (red), Revoked (blue).

Next steps

You now have a working internal PKI and a TLS-secured endpoint. To go further:

• Read the Certificate Manager reference for the full set of fields, ACME / Let's Encrypt support, and the Certificate Revocation List workflow.
• Secure more endpoints by repeating Step 5 for your OPC UA and MQTT connections.