Vision camera OPC UA client certificate not created: the fix

Anonymous reads from a vision cell work; you switch the security mode to Sign, handle the server's certificate, and then nothing happens on your side. ApplicationInstance.Default.AutoCreateCertificate is true, yet the client certificate never appears, and the session is refused at the trust check. That is the standard wall when an OPC UA client that ran open now has to authenticate against vision equipment. One cause dominates, two others support it, and all three are fixed in the configuration before the application instance is created. This guide gives the checks in order of probability, the trust arithmetic for a multi-server cell, and the security mode to commit to on a shared plant network.

The answer: auto-create is a fallback, not a command

Setting AutoCreateCertificate to true tells the SDK to create an application certificate automatically at startup, if none could be loaded from the configured store. Read that as a fallback that runs against a complete configuration. It is not a generate-now command, and it never raises an error: when its preconditions are missing it does nothing, and you find out later when the server refuses the session.

Three preconditions sit on your side of the fence:

1. The configuration names your own application certificate, meaning the store it lives in and its subject name. An empty own-certificate entry leaves auto-create with nothing to aim at.
2. Opc.Ua.CertificateGenerator.exe is available on the machine. The stack calls that tool to generate and sign the key pair; without it, the property stays true and nothing is built.
3. The store is writable by the account the client runs under, because generation writes the new certificate and its private key into it.

Fill in the own-certificate entry, deploy the generator, make the store writable, and the first startup produces the certificate.

Why anonymous mode hid the problem

Anonymous mode uses no certificate at all: no signature, no encryption, no trust exchange, so nothing on the client side was ever exercised. The asymmetry you noticed is real. OPC UA servers typically generate a self-signed certificate when they first start, which is why the server end of your link built itself. A client is code you host, and its stack does the same work only against a configuration that describes the certificate, and that configuration is yours to write.

Not every device in a cell speaks OPC UA at all. Older vision cameras without an OPC server report results over FTP and TCP, and the same who-initiates question comes up on plain camera links, where connecting to a vision camera over TCP, client versus server setup settles it before certificates enter the picture.

The four checks, in order of probability

Work top to bottom; the first two account for most cases.

The configuration does not name your own certificate

Test: print the application configuration your code builds, before any connect call. If the own-application certificate has no store location and no subject name, auto-create has nothing to work from. Fix: point the store at a directory the application owns, give the certificate a subject name, and create the application instance only after the configuration is complete.

Opc.Ua.CertificateGenerator.exe is missing

Test: search the client machine for the executable and start it from a command line. Fix: deploy it with your application, because it ships with the SDK's tools. While it is absent, no amount of configuration changes the outcome: the stack cannot do the key generation itself.

The store is not writable

Test: as the account that runs the client, for a service the service account rather than your login, create and delete a file in the store directory. Fix: create the directory, grant that account write access, or move the store to a location it already owns. A missing directory fails the same way.

A certificate exists but the session is still refused

When a certificate is present, loads, and the server rejects it anyway, compare the application URI inside the certificate with the URI your application announces. OPC UA certificates carry required extensions, the application URI among them, and the two must match; a certificate copied from another installation advertises that installation's URI. Test: read the certificate's URI and the configuration's side by side. Fix: generate on the machine that will present the certificate.

Worked example: one client, three controllers, SignAndEncrypt

Inputs: one OPC UA client application and three inspection cells acting as servers, all on one shared plant subnet, policy SignAndEncrypt. The client runs on a vision controller, and the MV-VC3301H-128G66 carries it with an Intel Core i3 and 8 GB of memory. Each cell is a vision controller such as the MV-SVC2506-16G60-128G, which gives cameras 4 GigE ports and separates 1 configuration and 1 communication GigE port from them. The cells' area scan cameras feed the controllers over the camera ports, so every certificate decision here sits on the communication link. Where a single smart camera serves its own results, it stands in as the server end of the same exchange.

Rule, in words: with self-signed certificates, every client-server pair costs two trust placements, the client's certificate into that server's trusted store and that server's certificate into the client's. The client generates one certificate and presents the same one to all three servers.

Arithmetic for this cell: certificates in play are 1 client + 3 servers = 4. Self-signed placements: 2 × 3 = 6. With a single authority: 4 stores × 1 authority certificate = 4 placements, and the authority issues the 4 application certificates afterwards.

Decision: at three pairs the authority already wins, 4 placements against 6, and every certificate issued later touches no trust list. At one or two pairs, stay self-signed; manual self-signed certificates give you complete Sign and SignAndEncrypt, and an authority buys scale, not strength. Part 4 of the OPC UA specification defines the certificate authority as the issuer whose certificates meet the deploying organization's requirements, which is exactly the role it plays here.

The exchange itself happens at first connect: each side refuses the other's certificate, and placing the refused certificate in the trusted store completes it.

Which security mode to run

Sign and SignAndEncrypt both need the client certificate this article fixes, so the mode choice does not change the repair. It changes what crosses the wire:

Run SignAndEncrypt on any shared subnet. The same store-and-trust mechanics, seen from the operator software side, are laid out in configuring secure OPC UA access with certificates.

Checks before you call the link secure

• One certificate in the client's own store after the first startup, its subject matching the configuration.
• Opc.Ua.CertificateGenerator.exe starts from a command line on the client machine.
• The service account can create and delete a file in the store directory.
• The application URI inside the certificate matches the URI the application announces.
• The client's certificate sits in every server's trusted store, and every server's certificate sits in the client's.
• The endpoint's mode reads SignAndEncrypt on any shared subnet.

When the usual advice is wrong

"Delete the store and restart" is a clean fix for one corrupt certificate on the bench. On a running system it also drops the trust entries the servers already accepted, and you repeat the exchange on every store. "Copy the client certificate from the other machine" fails the URI comparison and leaves one private key in two places. "Turn security off until it works" removes the check instead of passing it, and nothing learned in anonymous mode says anything about the trust path.

Once the secure channel is up, the next surprise is usually on the information-model side: OPC UA companion specification nodesets must be imported in the right order or the address space comes up short. To equip the host side, start from the vision controllers category, and if your cell count is past three, bring it to us through the contact page and we will size the certificate layout with you.