The BadCertificateHostNameInvalid is not related to ApplicationUriString.

Can you please check the server certificate, and specifically, the domains it is supposed to be for? The domain may be simply a computer name (such as TEST-PC), or a fully-qualified host name (such as test-pc.mydomain.com). One of the domains has to match the host name in the URL of the endpoint used.

The OPC spec does not say much of ApplicationUri-s for the clients, but the logic says that similar approach as for servers should be used. For servers: "This identifier should be a fully qualified domain name; however, it may be a GUID or similar construct that ensures global uniqueness."

The bottom line is as I wrote earlier: Make sure it is something that would not conflict with another application, and you will be OK. I recommend to keep it conformant with the URI syntax.

I can only give you detailed answers after I am back in office - January 3.

Short ones:
- The value of ApplicationUriString isn't that important, as long as it conforms to URI syntax and is unique
- BadCertificateHostNameInvalid: you can turn it off by setting CheckEndpointDomain to false as indicated, OR make the server (or connection URI) use the proper host name.

More on this later

Regarding the remainder of your questions:

Ad 1. There may be various reasons. For example, when you first run your application your development computer, you may use the development Web server built-in in Visual Studio. This one uses different accounts and permissions from IIS, and the certificate creates just fine.

Ad 2. Most likely this is due to permissions. IIS settings are VERY restrictive (for good reason), and the feaults won't allow the certification generation or storing it into the store.

Ad 3, ad 5. The default certificate store for OPC-UA applications is not one of the Windows stores, but instead, a file-system (directory) based store. It defaults to "%CommonApplicationData%\OPC Foundation\CertificateStores\UA Applications", where %CommonApplicationData% is e.g. "C:\ProgramData". The best way to inspect the UA certificates is to run Start -> All Programs -> OPC Foundation -> UA SDK 1.01 -> UA COnfiguration Tool. Then, select the "Manage Certificates" tab, press the drop-down next to "Store Path", select the store I listed above, and press the "View Certificates" button.

Ad 3. You should not use the same certificate for multiple applications. And, you should not use the same certificate even for multiple instances of the same application (such as when you deploy the application on multiple computers). Each instance of the application (typically, this means each application/computer combination, but can be even more) should have its own, unique certificate. This is how UA security is meant to work, because there needs to be a way for the server to authenticate each client connection separately and possibly deny the connection to unsecure or compromised clients. Technically, if you violate this and use the same certificate, things will probably work OK on the surface, but it is against the OPC-UA security specs. This is the reason why the certificate is generated anew on the computer - and the cause of some troubles.

Actually, while using the CertificateGenerator manually is possible, it would be probably too complicated to try to assemble the right set of parameters so that the generated certificate is then properly found by the client application. Instead, I suggest that you create a small Windows based (e.g. Windows Forms app, or a console app). In it, you set the 4 parameters in EasyUAClient.SharedParameters to meaningful values, and then call a static method EasyUAClient.Install(). You then run this application with administrator/elevated privileges, and it will create the certificate (verify it with the UA Configuration Tool described above). In your actual client app, set the parameters in precisely the same way before instantiating the EasyUAClient object, and doing so should assure that it will find and use the certificate (still, the Web app needs to have read access to the directory of the cert store - you may have to modify the permissions). The additional app you created may become part of your installation procedure.

Best regards

To #4: Apparently, "/?" only works with the newer version I was accidentally using. Use "-?" instead with older versions.

Will answer the remainder of your points separately.

Best regards

Thank you very much for the information, it is really helpful.

It appears that there are two issues at play:
1) Problem creating the OPC-UA client application certificate. This may be working as designed (details below), but still you will need to take extra steps to resolve it.
2) Insufficient/incomplete error reporting. This is more or less a bug in QuickOPC. In case of the problem, you were supposed to receive an exception or a log message (or both) with details about the cause, and not just "engine not connected". Thankfully, you have noticed the original exception in the Debug Output.

We will work on improving the error reporting (2). This would not, however, resolve the actual problem (1). For it, however, I have a likely explanation, and instructions.

OPC-UA requires that both parties (client and server) mutually identify themselves using application certificates. The certificates are supposed to be unique for each application (instance), and therefore cannot be a constant part of the "toolkit" (such as QuickOPC), and need to be generated. In order to make this process invisible (in common cases) to the developer, QuickOPC
a) determines the parameters of the certificate automatically, using values such as the EXE name or the calling assembly name,
b) attempts to look up the certificate in the certificate store,
c) if not found, it attempts to create it, and save it into the certificate store.

The algorithm described above does not, however fit well wit hosted environments such as IIS, for two reasons:
- It is difficult to automatically determine reasonable and unique parameters for the certificate, because the hosting process is the IIS service, not "your" own application EXE.
- The page processing code in IIS typically runs with low privileges that do not allow it to call the necessary CertificateGenerator utility, and even less to save the new certificate to the store.

For usage in such environments, the recommendation is:
- Pre-generate the application certificate manually, and save it to the certificate store. This will remove the need for the application to create and save the certificate.
- In your application, set your own parameters of the certificate. The application will then use these parameters to look up the certificate.

Application certificate can be generated using Opc.Ua.CertificateGenerator.exe utility, typically located (after QuickOPC installation) at C:\Program Files (x86)\Common Files\OPC Foundation\UA\v1.0\Bin. Run it with "/?" to obtain usage instructions.

Setting the certificate parameters is done by modifying properties in EasyUAClient.SharedParameters.Engine (EasyUAClient.SharedParameteres is a static property, and you need to set the values before creating the first instance EasyUAClient, in order for it to have the desired effect). The properties of interest are:
- ApplicationCertificateSubject
- ApplicationName
- ApplicationUriString
- ProductUriString

The values should match those used when the certificate was generated, because they (or at least some of them) are used to look up the certificate in the store.

I understand that the above instructions may need further details or explanation; let me know which parts need more attention and I will try to help.

Best regards