UA server access is handled through the OPCDA.NET application interface.
To access a UA server the application need to specify a UA server URL, prefixed with "ua:" instead of the HDA server ProgID.
e.g. ua:opc.tcp://localhost:62849/Advosol/uaSim
How the UA server access is handled can be controlled thru properties in the OPCDA.NET.OpcServer class. These must be set before the server is connected.
- public bool UaAccessWithoutSecurityPreferred
Request to access the UA server with lowest security if true (using the endpoint with lowest security level), otherwise with highest (default).
- public Opc.Ua.ClientDA.EndpointDescription preferredEndpoint
For UA server access use this endpoint at connect if possible.
The specified endpoint must one of the endpoints returned in the DiscoverEndpoints() result for this UA server.
- static public string UaAppConfigFileAutoCreate
If not null then a default application configuration file is created unless it already exists. The defined name is used as the application name.
This option is convenient for testing and samples. Deployed applications may require application specific settings.
In this case the UA configuration file needs to be created with the configuration utilities.
Sample:
OPCDA.NET.OpcServer.UaAppConfigFileAutoCreate = "OPCDA.NET-UA Test Client"; //auto create a default UA config file
- public static Opc.Ua.Client.dlgNotifyUntrustedCertificate onNotifyUntrustedCertificate
Defines a handler that is called when the certificate provided by the accessed server is untrusted.
The handler can accept or reject the certificate.
Sample:
....
OPCDA.NET.OpcServer.onNotifyUntrustedCertificate = OnNotifyUntrustedCertificate;
}
//---------is called when a UA server certificate is untrusted
private int OnNotifyUntrustedCertificate(string certificateName)
{
if (this.InvokeRequired)
return (int)Invoke( new UA_Wrapper.NotifyUntrustedCertificate(ShowUntrustedCertificate),
(object)certificateName);
else
return ShowUntrustedCertificate(certificateName);
}
private int ShowUntrustedCertificate(string certificateName)
{
DialogResult dr = MessageBox.Show("The server certificate is not trusted. Do you want to accept it ? "
+ "Click CANCEL to accept it for this session. Click YES to accept it permanently.",
"UA Server Access", MessageBoxButtons.YesNoCancel);
if (dr == DialogResult.Yes)
return 1; // accept permanently
if (dr == DialogResult.Cancel)
return 0; // accept for this session
else
return -1; //reject
}
UA Configuration File
OPCDA.NET-UA based UA client application require a configuration file with the name appname.UA.Config.Xml
appname is the name of the application executable.
The configuration file must contain the settings required by the UA wrapper. See UA Security for details.
The file can be created/edited with the UAClientConfigHelper utility.
The UaClientPrepare command line utility can be used in installers to create an application specific file.
A default configuration file is automatically created if the application sets the UaAppConfigFileAutoCreate property. See above.
UA Certificates
UA uses X509 certificates to authenticate client and server application domains. See UA Security for details.
UA clients must create a certificate and the server must know this certificate as a trusted certificate.
The client must know the server certificate as a trusted certificate before the server can be connected.
OPCDA.NET-UA manages certificates in the Windows Certificate Store.
The UAClientConfigHelper utility creates and exports client certificates and imports server certificates.
UA applications from different vendors may use different certificates stores and certificates may have exchanged even if server and client run on the same machine.
Accepting untrusted server certificates can be handled in the OPCDA.NET-UA based client code if the application defines a handler in the onNotifyUntrustedCertificate property. See above.
Accepting server certificate with invalid host name
Certificates are issued for a domain (machine name in a LAN) and are used to certify that responses from the server actually come from teh domain of the accessed UA server.
Some server installations copy the certificae instead of issuing a new certificate for the domain. This causes secure connections to fail with error BadCertificateHostNameInvalid
Some UA applications ignore this error and accept certificates issued for another domain, despite this nullifying the main purpose of using certificates.
EasyUA by default fails secure connections to a server with a certificate for another domain. To access such servers anyway (with reduced security) the check can be disabled by setting the property
OpcServer.CertificateDomainMustMatch = false;
after the OpcServer instance is created and before Connect() is executed.
If a onNotifyUntrustedCertificate handler (see above) is defined then domain errors cause the handler to be called and the certificate can be accepted for the instance. Only setting CertificatesMustMatch=false forces permanent certificate acceptance.
Server accepting the client certificate
If the UA server is on another machine or uses a different certificate store than EasyUA then the certificate created for the client appliation is not known/trusted by the server.
The procedure to accept the client certificate as a trusted certificate depends on the server. If the server has a user interface then there may be a dialog to accept the certificate. Otherwise the server documentation should explain the procedure.
Some servers store untrusted certifcate in a 'untrusted' certificate store, which may be a directory. The operator then can move the certificate to the 'trusted' certificate store to declare is as trusted.