Trusting Certificate from Server running as Worker Service|OPC UA Standard|Forum|OPC Foundation

When you say turn on “server logging”, which section to which are you referring?

For instance, do you mean enabling diagnostics, i.e. in the Server.Config.XML file => <DiagnosticsEnabled>true</DiagnosticsEnabled>

-OR-

I also tried logging the following details within the event handler: CertificateValidationEventHandler()

e.Error.StatusCode.ToString();
e.Error.AdditionalInfo.ToString();
e.Error.InnerResult.ToString();

Which returned:

Status code => BadCertificateUntrusted

Additional Info: >>> Certificate is not trusted.
SubjectName: CN=OPC UA Client, C=US, S=Pennsylvania, O=Sentinel Software, DC=localhost
IssuerName: CN=OPC UA Client, C=US, S=Pennsylvania, O=Sentinel Software, DC=localhost

— at Opc.Ua.CertificateValidator.InternalValidate(X509Certificate2Collection certificates) in …\Opc.Ua.Core\Security\Certificates\CertificateValidator.cs:line 846

— at Opc.Ua.CertificateValidator.Validate(X509Certificate2Collection chain) in    …\Opc.Ua.Core\Security\Certificates\CertificateValidator.cs:line 247

Which points to this exception on line 846 of CertificateValidator.cs:

if ((certificateKeyUsage & X509KeyUsageFlags.DataEncipherment) == 0)
{
     throw new ServiceResultException(StatusCodes.BadCertificateUseNotAllowed, “Usage of certificate is not allowed.”);
}

And the other points to this statement on line 247 of CertificateValidator.cs:

m_validatedCertificates[certificate.Thumbprint] = new X509Certificate2(certificate.RawData);

Thanks!

Please advise.

The certificates are automatically created by the OPC UA stack.

I found the solution and proper configuration for running the server as a windows service. I’m going to outline my process, in case anyone who wants to do the same thing comes across this post.

One main difference to highlight is the fact that %LocalApplicationData% resolves to the special profile folder that is associated with the service. By default, a windows service logs on as “Local System” which means that %LocalApplicationData% will resolve to:

“C:\Windows\System32\config\systemprofile\AppData\Local”

That being said, CurrentUser/My cannot be used with this configuration, it will just silently fail to place the cert here. There may be a workaround here, but I haven’t found it as of yet. However, because the cert is still being placed in the trusted location, the client will still authenticate properly with the server upon connection.

If a X509 store must be used, LocalMachine/My should be used. A directory type store will also work just as well if you want to skip the windows cert stores. I chose LocalMachine/My for my implementation, but of course it depends on your need.

Now, finally since %LocalApplicationData% is no longer a reliable place to store the trusted/issuer/rejected certs, I’ve found that %CommonApplicationData% provides a nice alternative special folder location and will work just fine. Of course, you could use whatever directory you want, but wanted to provide that insight.