OPC UA Certificate Renewal Checklist

Why certificate renewal deserves a plan

OPC UA security is useful only when the certificate lifecycle is treated as a maintenance task, not as a surprise outage. Many stable SCADA links fail years after commissioning because an application certificate expires, a trust list is overwritten, or a gateway is replaced with a new certificate thumbprint.

The goal is simple: renew certificates while proving that every client and server still trusts the right application identities.

Inventory before touching anything

Start with a small table. Do not rely on memory or screenshots from the original project.

Item	Record it
OPC UA application name	The exact name shown in the certificate and endpoint.
Role	Server, client, gateway, historian collector, engineering tool.
Hostname and IP	Include NAT or alias names if clients use them.
Endpoint URL	Example: opc.tcp://plc-gateway-01:4840.
Current certificate expiry	Date and time, including timezone if available.
Trust list location	File path, vendor UI page, or certificate store.
Restart requirement	Whether applying the certificate restarts a service or driver.

Field note: on mixed-vendor systems, the certificate may be tied to the OPC UA application, not just the Windows machine or Linux host. Reinstalling the runtime can create a new application certificate even when the hostname stays the same.

Pre-renewal checks

Before replacing anything, confirm the current system behavior.

• Export or back up the current application certificate, private key where appropriate, and trust list.
• Capture the active endpoint URL, security policy, and message security mode.
• Confirm which clients are connected and whether any run from standby nodes.
• Verify time synchronization on the client and server. Bad clocks make valid certificates look invalid.
• Check whether the certificate subject alternative names include the names clients actually use.
• Identify who can approve trust prompts if a vendor tool requires manual acceptance.

If the link is production-critical, arrange a rollback window. A certificate task should not be mixed with unrelated driver upgrades unless the outage window explicitly covers both.

Renewal sequence

A controlled renewal usually follows this order:

1. Generate or import the new server application certificate.
2. Confirm the certificate includes the expected application URI and DNS/IP names.
3. Install it in the server application certificate store.
4. Restart only the required OPC UA service or runtime component.
5. From one test client, attempt a secure connection and capture the trust rejection if expected.
6. Move the new server certificate into each client trust list.
7. If client certificate authentication is used, make sure the server trusts each client certificate.
8. Reconnect production clients one at a time where possible.
9. Verify live data, quality, subscriptions, alarms, and historian collection.
10. Archive the old and new certificate details with the commissioning notes.

For redundant systems, renew the passive or standby side first when the architecture permits it. Then fail over, verify, and repeat on the other side.

What to verify after reconnecting

A green connection icon is not enough. Check behavior that proves subscriptions and data quality survived the change.

Check	Evidence to capture
Session connects securely	Client diagnostic screen or log entry.
Expected security mode is active	No silent fallback to None unless intentionally allowed.
Live values update	Timestamp or changing process value.
Item quality is good	No BadSecurityChecksFailed, BadCertificateUntrusted, or stale quality.
Alarms/events arrive	Force a safe test event or use a known simulator point.
Historian stores samples	Recent value visible in trend or archive query.
Standby node works	Test the redundant path, not only the active node.

Keep the first test narrow. Prove one client-to-server path, then repeat the same checklist for each remaining client.

Common mistakes

• Renewing the server certificate but forgetting historian collectors and edge gateways that also trust it.
• Changing the endpoint hostname while the certificate only contains the old DNS name.
• Letting engineering laptops auto-trust certificates and assuming production clients will behave the same way.
• Copying a certificate without the matching private key when the application expects both.
• Restoring an old VM snapshot after renewal and accidentally bringing back an expired certificate.
• Leaving security policy set to None after troubleshooting.

Minimal handover record

Add a short record to the project folder:

• Certificate subject, issuer, thumbprint, serial number, and expiry date.
• Application URI and endpoint URL.
• Security policy and message mode used in production.
• List of clients and servers updated.
• Time of restart or failover.
• Test evidence: live tag, alarm/event, and historian sample.
• Rollback notes and location of backups.

Field note

Treat certificates like calibration dates. They are not exciting, but they are predictable. A small renewal log prevents the next engineer from discovering the trust chain during a 2 a.m. communication outage.