Skip to main content
When working with OPC UA in Node-RED, managing SSL/TLS certificates is essential for secure client-server communication. If these certificates expire or are misconfigured, connections will fail with often cryptic errors. This guide walks through how to renew certificates for both the OPC UA server and client, including paths, formats, and best practices for avoiding common pitfalls.

Why Renew Certificates?

  1. Certificates typically have a validity period (e.g., 1 year).
  2. When expired, OPC UA clients and servers will reject connections.
  3. Renewing involves generating a new certificate, replacing old files, and restarting Node-RED.

Replacing the Server Certificate

If you’re using the node-red-contrib-opcua-server module, replace the server certificate as follows:
Place your renewed files here:
  • public.pem — your public certificate
  • private.pem — your private key
Make sure Node-RED has permission to read the new certificate files. On Linux, you may need to run:
If you’re running Node-RED as a system service, permissions are especially important to avoid startup errors.
After replacement, restart Node-RED to apply the changes.

Replacing the Client Certificate

If Node-RED is acting as a client to connect to an OPC UA server (using nodes like node-red-contrib-opcua-client), it stores its identity certificate in:

Client Certificate Location (Windows)

Ensure that:
  • Files are in .pem format
  • File names match expectations (public.pem, private.pem)
  • Permissions allow Node-RED to read them

Client Certificate Location (Linux)

Ensure that:
  • Files are in .pem format
  • File names match expectations (public.pem, private.pem)
  • Permissions allow Node-RED to read them

Required Certificate Extensions

When generating your certificate, ensure the following X.509 extensions are set to avoid handshake errors:
Without these, clients or servers may reject the certificate with errors like “certificate not trusted” or “bad certificate usage.”

Common Name (CN) and Subject Alternative Name (SAN)

The Common Name (CN) in your certificate must exactly match the hostname used in your OPC UA connection.
Example: If your client connects to opc.tcp://my-server.local:4840, the CN should be my-server.local.

Subject Alternative Name (SAN)

Modern clients (including browsers and OPC UA stacks) often require SAN fields. You can include them using OpenSSL config:
Without SANs, even a valid CN may be ignored by some clients.

Generating New Certificates with OpenSSL

Here’s an example openssl.cnf snippet you can use:
And the command to generate:

Troubleshooting Tips

If you’re running into issues even after replacing the certificates, here are common things to check:
  • Make sure the CN and SAN match the endpoint host
  • Ensure the files are .pem format, not .crt or .der
  • Verify certificate is not expired:
  • Check that the certificate has the correct keyUsage and extendedKeyUsage fields
  • Ensure correct file permissions so Node-RED can access the certs
  • Include the full certificate chain if using a CA-signed certificate (some clients require intermediate + root certs)

Summary Table

Automating Certificate Renewal (Optional)

If you manage multiple environments or frequent testing, consider automating the renewal process: Example Linux script could:
  1. Generate a new certificate via OpenSSL
  2. Copy it to the appropriate folder(s)
  3. Restart Node-RED (systemctl restart nodered.service)
Always validate certificates in a test setup before deploying to production.

Community Contribution

Special thanks to Jeff Cooper, who shared additional paths and practical fixes that helped improve this guide.