Thank you,

this is interesting.

Can you try to copy the whole "C:\OPC Foundation" structure over to "c:\ProgramData\OPC Foundation"? (keeping the original contents where not replaced).

And, if you still get error, be careful in reading its details. It is really the same as before? (if things start working regarding the client certificate, the next common error is the validation of the server certificate, which looks similarly but is different).

Best regards

Hello,
and thank you very much, this has helped.

There are entries in the log that indicate where the problem is probably coming from, such as:

The directory is not correct - it should be "c:\ProgramData\OPC Foundation\CertificateStores\MachineDefault". In the component configuration, it is defined as "%CommonApplicationData%\OPC Foundation\CertificateStores\MachineDefault", and %CommonApplicationData% should resolve to "C:\ProgramData", but it appears that under this host, it resolves to an empty string.

Will investigate further - but cannot do so right now, I am out of office this week. Possible workaround that come to my mind, and that we can explore then:

A ) Create the "incorrect" folder (folder structure) and provide permissions to it.
B ) Change the component configuration so that it specifies an absolute path directly and not with the %CommonApplicationData% symbol.
C ) Create the certificate manually and place it to the correct place.

You can provide try A ) yourself; instructions might be needed for B ) and C ).

Best regards

Hello, and thank you.

Regarding #3: This looks like misunderstanding. What you have posted is probably the outcome of the ReadValue operation in the example. But I wanted the whole series of events, the stuff that comes to the "function LogEntry($Sender, $E)". Obviously, the example is for PHP under console, you will need to modify it a bit to capture the incoming events somehow.

Regards

Thank you.

The outcome is not precisely the same, there is now "+CGI + FastCGI+ [ABD53CDFA4029CC6E79A96ACFC62C33C408EFFDA].der" in "c:\ProgramData\OPC Foundation\CertificateStores\UA Applications\certs", and I assume this is for the Apache process. This is good.

However, the correct outcome would be that also
1. This file is also in "c:\ProgramData\OPC Foundation\CertificateStores\MachineDefault\certs". This couldbe fixed simply by copying it in there, BUT it's of no use without:
2. A file with the same name but .PFX extension would be in "c:\ProgramData\OPC Foundation\CertificateStores\MachineDefault\private". This will contain the private key of the certificate. Without it won't work, unfortunately.


Can you please answer additional questions:
1. Which version&build of QuickOPC are you using?
2. Are you absolutely sure that the permissions on folders under "c:\ProgramData\OPC Foundation\CertificateStores\MachineDefault" also allow writing from the Apache server?
3. Can you please collect and report here the events generated by QuickOPC - see opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...PC%20UA%20event%20logging.html .

Best regards

Thank you.
These are directories for OPC UA certificates. QuickOPC needs to have its own application certificate there. But, the certificate is not present...

Unfortunately, Web servers are tightly secured (for good reason), so the most likely reason is that the process that you app runs under does not have the necessary permissions to that folder structure.

There are two parts to this issue:

1) The process/the user account the Web server is is running *must* have read permissions to these folders. For secure OPC UA communication, there is no way around it. (to be more precise, it is possible to configure QuickOPC to use different directories elsewhere, if that would help; but the principle remains the same - the read access is needed)

2) Somehow, the application certificate must be placed onto the right spots in this directory structure.

2a) If the process/user has also write permissions to the folders, QuickOPC will automatically create the certificate and placed it there. If you can also grant write permissions to the Web server account *once*, only for this to happen, and then to set the permissions back to read-only, it should be enough.

2b) If you cannot do the above, there are ways to create the app certificate outside the application, and then you would manually copy it into the right place. That is a fairly involved sequence to describe, so let's go this way only if you cannot do 2a).

Best regards