Hello,
I am glad you got it working.

Regarding the type mismatch, may I ask you to create a new forum topic?

Regrads

Summary of non-confidential information from fact finding over email:
- The "C:\ProgramData\OPC Foundation\CertificateStores" directory on the client machine contains the expected structure and certificates, but the server certificate is not trusted
- The target server is currently running on the same computer as the client, but in other system configurations it may also be on a different computer
- The target server uses a location different from "C:\ProgramData\OPC Foundation\CertificateStores" for its certificate storage

General information to OPC UA security: In general there are following security modes: insecure (MessageSecurityMode=None) and secure (MessageSecurityMode=Sign or SignAndEncrypt). The server and the client negotiate the security mode.
- When any secure mode is used, application certificates (from both sides) MUST be exchanged. There is absolutely no way around it. The client and the server also verify the certificate of the other side. The verification step, in theory, can be suppressed if the server or client allows it (QuickOPC has such a setting), but that should be reserved for testing/troubleshooting purposes.
- When insecure mode is used, whether the certificates must be present and exchanged depends on the precise version of the OPC UA protocol. Older versions required it; in the current version the exchange of certificates is optional when MessageSecurityMode=None.

General information to QuickOPC behavior:
- In the default state, if the server exposes an endpoint with MessageSecurityMode=None, QuickOPC will try to use it. This means that it will neither require nor verify the server certificate. The fact that the EasyOPCUADemo application has asked you for confirmation of the certificate is a clear indication that the server did NOT expose an endpoint with MessageSecurityMode=None at that time. From that, I can conclude that a) EasyOPCUADemo is using secure communication with certificates, and b) I think UaExpert and Matrikon's OPC UA Explorer are doing the same; you just forgot that at some point, a similar dialog was presented to you and the server certificate made permanently trusted in these tools.


Comments and answers related to the email exchange:
- "Can QuickOPC OPC UA object call(s) be made to work inside web application (classic ASP) without certificates […]? ". If the server had exposed an insecure endpoint, the answer would be Yes. But it currently does not expose an insecure endpoint (it may be configurable), therefore with the current server configuration the answer is No.
- "[…] can you provide details of steps needed to setup QuickOPC OPC UA object accordingly? ". Steps to make the server certificate trusted are described in QuickOPC User's Guide. In your case, in the "C:\ProgramData\OPC Foundation\CertificateStores" structure, simply copy the rejected server certificate, which is in "opcua_server [91E2037134DEC9FB9D7725CB0857890CCF8A0EF1].der" file, from RejectedCertificates\certs to UA Applications\certs . Note that after doing this, the error might change to something like BadSecureChannelClosed. This is expected. You now need to also tell the server to trust the client certificate. This is server specific and you should consult the server documentation on that.
- The server and client can very well be on different machines, and the only thing that changes is the endpoint URL of the server. The reason why the "which software is on which machine " issue came in the conversation was because it was not clear how your current system is set up and to which part of it your answers apply.
"[…] does that imply QuickOPC should be installed on the same machine running IIS?". Yes. I thought that was clear. Your ASP script in the IIS is instantiating COM objects (of QuickOPC) that need to reside there. But the QuickOPC objects can then connect to servers elsewhere.

Regards

Hello.

In this case the likely reason of the error is that the client (your app) does not trust the server. In a secure OPC UA system, this is an expected and good thing. You are expected to specify which servers your application trusts, otherwise the application could be tricked to communicating with a malicious server.

Please verify that your system contains following directory: "C:\ProgramData\OPC Foundation\CertificateStores".
If so, start command line (with elevated privileges), switch to that directory, and enter command
Then, post the contents of the 'out.txt' file here (or email it to support09 (at) opclabs.com if privacy is a concern).

Best regards

Hello,
I am confident we can make this work, but it will need multiple steps.

For start, I have some questions:

1. When you wrote "QuickOPC OPC UA object call is returning “error '80131600'” error", which line specifically is returning the error? Can you post your code and identify the line?

2. Is "“error '80131600'”" all the error info you could obtain? I would expect that if you do "On Error Resume Next", then there should be more interesting stuff in the Err object - mainly, the Err.Source and Err.Description properties - what values do they contain?

To your questions:

QuickOPC has a built-in user interface for dealing with some situations, like an untrusted certificate. However, that only works in console applications, and Windows desktop application. It does not work inside Web applications. I can point you to the place in our User's Guide that described this, but since you indicated you want to do ASP, you probably do not actually need that because you cannot use it.

It is quite possible that the error you are getting is also related to the certificate verification. I can help with that too, but I need the answers to the questions first.

Best regards