Hello, and thank you. You gave me some stuff to think about. Ideally, we would somehow satisfy both worlds - maintain the design principles I described, and support custom certificate validation too. I do not think it is fully possible, but perhaps we can offer a separate "mode" of operation in which the custom validation will be used. Obviously this is not something to be implemented in short term. If this feature is a "must", our library is probably not for you.

If you like, we can go on troubleshooting path, and try to determine the exact cause of the certificate validation failure. Let me know if you are interested in it. Sometimes the reasons are different from what one would guess.

But you might be right about the relation CRLs. In fact, in OPC UA the expected mechanism to distribute trust lists *including* CRLs is via the OPC UA GDS (Global Discovery Server), which is usually front-ending some CA. And the usual CRL distribution points (URLs) are not used. CRLs are then located inside the OPC UA certificate stores. This is possible with OPC UA directory-based certificate stores, which have "crl" subdirectory for it. But, Windows certificate stores (which you mentioned you are using) cannot store CRLs.

An online CRL check might also be possible, and we can look into it, but first it would be necessary to know for sure what the cause of the certificate validation failure is in your case.

Hello.

Thank you for the detailed feedback, I really appreciate it. I feel that I have to provide more elaborate explanation of our design as well, and address at least some of the points you raised.

There is a large amount of effort that went and goes into QuickOPC. Implementing the "hook" for custom certificate validation would be a minor deal in terms of work amount - if we decided to do it. But, it is not for bad prioritization or laziness that we do not have it, and it is also not *just* because of the reason you mention - the goal to provide quick/easy development. There are more important reasons. The two most important ones are:

1. Consistency in the QuickOPC design principle in which whatever information is necessary to access the target should be specified by *data*, and not *code*. Hooking a custom certificate validation requires code, and makes it impossible to describe the intended behavior just by listing the properties of participating objects. There are higher-level features that depend on the principle. For example, you won't be able to simply serialize the endpoint/node descriptor from one program to other program, and be sure that it works - because the hooks (the code behind them) don't get serialized. On even higher level, in the reactive programming model, the streams of notifications are treated as pieces of data that you can manipulate, combine, transfer around…. And none of that works if there is code attached to objects that does not serialize.

2. Security. The certificate validation algorithm is one of the critical pieces of OPC UA security architecture. The details of the certificate validation procedures are quite long, and they get improvements and clarifications in practically every revision of OPC UA specifications. The corresponding code in the library matches the specifications. When we provide properties that allow you to influence the validation, and you change them, it is blatantly obvious that you are affecting the security, and each property tells you what effects it has. So even if you decide to turn the validation off (and I agree - this is not for any production use, it is just for troubleshooting), you at least know that you did it. Or, if you decrease certain aspect of the security, again you have to explicitly specify that. Allowing developers to fully override the validation by their own code is a recipe for security disaster. 99.9% of developers who will do it will *think* they have done it securely, but there will be insecurities in their code. Believing that you are secure, while you are not, is worse than knowingly turning the security off.

It is true the users are often struggling with getting the certificates right in OPC UA. It is either because they do not understand the underlying concepts, or that they do not understand the particular implementation or behavior we have - which, however, is not much different from what other products do. And we are trying various measures to make the whole process less painful. The tech support issues, however, rarely call for resolution through the custom certificate validation. In fact, you might be the 2nd or 3rd over many years. In normal cases, there is a more appropriate solution - which simply consists of having the right certificates in the right places. Trying to get around that with custom validation would be *guaranteed* to be insecure.

I am totally with you on your other recommendations, such as guiding the users from the concrete/visual to the more abstract concepts - we will try to incorporate this.

I have re-read your original entry, and I am trying to understand how your requirements look like. When you wrote "Our network security policies require that we use our existing internal certificate infrastructure…", does that mean that you cannot use the certificate stores (directory based or platform-defined) to hold the certificates? Or, are you saying that perhaps the certificate storage is OK, but you must obey specific requirements for certificate validation that are different from what is implemented in QuickOPC? In the latter case, if you requirements were in any relevant aspect "looser" than what is mandated by OPC UA specifications, following such requirements will not be compliant with the OPC UA specs - and that is simply not what we are making our product for.

Best regards

Hello.
No, there is (by design, although we may reconsider it in the future) no such hook.

There are settings in CertificateAcceptancePolicy (which can be set globally or overridden on specific endpoint) that can be used to influence which certificates are accepted. I am listing some of them below. But, if the setting you are looking for is missing, there is currently no way (well, the AcceptAnyCertificate can always do it, but that essentially turns off *any* certificate check).

- AcceptAnyCertificate
- AllowSha1SignedCertificates
- CheckTimeValidAndNested
- MinimumCertificateKeySize
- RequireRevocationStatusKnown

Regards