Hey all,
CPU 1516F-3 PN/DP, TIA V17, OPC UA server switched on at the CPU, and Node-RED on a small edge box with the node-red-contrib-opcua client node. With the policy set to None the client connects and reads fine. Soon as I set Basic256Sha256 with Sign and Encrypt it drops out with BadSecurityChecksFailed in the Node-RED debug, and the CPU diagnostics buffer has a line about a rejected client certificate. I'll copy that out tomorrow.
So I regenerated the client certificate in the node, no change, then checked the CPU's own server certificate in the OPC UA settings and it's there and valid. Smallest test I could think of after that was UaExpert off my laptop with the same policy, and it fails the same way, so it's the CPU side and not Node-RED.
What's it rejecting? Is there a trust list on the CPU side that the client certificate has to go into before it'll stop rejecting it?
Two things I'd check. Does the CPU have the OPC UA runtime licence, the SIMATIC OPC UA S7-1500 one? I've read it isn't enforced technically but I'm not sure of that.
And is 4840 reachable from where the client sits? In V17 the server port is on the same OPC UA page. The firewall you opened is on the client, so that shouldn't matter.
Licence is bought, and None works, so the server's up and serving. 4840 is the CPU's listening port and there's nothing in front of it.
Buffer line from this morning, roughly: "OPC UA server: client certificate rejected, not trusted", with the client's name after it. So it's trust, not policy.
It is. With None the CPU never looks at your certificate. With Sign and Encrypt it checks the client certificate against its trusted list, and yours is not in it. Everything else was the wrong layer.
In TIA, CPU properties, OPC UA, Server, Security, Secure channel. There is a checkbox for accepting client certificates automatically during runtime, and a trusted clients list. For a test, tick it, download, connect once, it appears. For anything you keep, leave it off, export the client certificate from Node-RED as a .der, import it in the Certificate manager under Trusted certificates, add it to the server's trusted clients, download. Use global security settings has to be on first or the manager is greyed out.
Post the exact error if it changes. Decent article on the certificate side: https://plctr.com/introduction-to-opc-open-platform-communications-for-plc-integration/
Auto accept ticked as a test, downloaded, connected first time with Sign and Encrypt. Reads fine.
Then I unticked it, imported the .der, added it to trusted clients, downloaded. Now it's failing again, BadSecurityChecksFailed, same as before. No luck.
Is the node still presenting the certificate you imported? Compare the thumbprint in the CPU's trusted list with the one the node is using now.
That was it. The node had a fresh certificate in its own folder, I think from the module update that week, and the .der I exported was the old one. Pointed the node at a fixed cert and key on disk, exported that one, imported it, trusted clients, downloaded. Sign and Encrypt connects now and stays up across deploys.
So the certificate was never in the CPU's trusted list, and second time round I'd trusted the wrong one. Certificate manager in V17, Trusted certificates, add it to the server's trusted clients, and give the client a fixed certificate file so it stops changing under you.
The auto accept checkbox put that first cert in the list and I still can't find where to delete it.
Thanks suel and kiran_s.
Nine times in ten it's the trust list. The tenth, the application URI.