Renewing SSL Certificates
If your node-red-contrib-opcua-server has been running for a while and the SSL certificate has expired, here's a clear and practical guide to replacing it with a new one.
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?
Certificates typically have a validity period (e.g., 1 year).
When expired, OPC UA clients and servers will reject connections.
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:
~\.node-red\node_modules\node-red-contrib-opcua-server\certificatesPlace your renewed files here:
public.pemβ your public certificateprivate.pemβ your private key
β οΈ Make sure Node-RED has permission to read the new certificate files. On Linux, you may need to run:
chmod 600 private.pem
chown node-red:node-red private.pemAfter 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
.pemformatFile names match expectations (
public.pem,private.pem)Permissions allow Node-RED to read them
π§ Client Certificate Location (Linux)
Ensure that:
Files are in
.pemformatFile 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.
π 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
.pemformat, not.crtor.derβ Verify certificate is not expired:
β Check that the certificate has the correct
keyUsageandextendedKeyUsagefieldsβ 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
OPC UA Server
~\.node-red\node_modules\node-red-contrib-opcua-server\certificates
public.pem, private.pem
OPC UA Client
%APPDATA%\node-opcua-default-nodejs\Config\PKI\own\{cert, private}
public.pem, private.pem
π€ Automating Certificate Renewal (Optional)
If you manage multiple environments or frequent testing, consider automating the renewal process:
Example Linux script could:
Generate a new certificate via OpenSSL
Copy it to the appropriate folder(s)
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.
Last updated
Was this helpful?