Hello.

1. GDS can function as PKI server, yes.

2. Yes.

3. This would be "server redundancy" in OPC UA terms. It is certainly possible, but in such case the OPC UA apps that connect to GDS will have to support the redundancy for that, plus the GDS will somehow have to have the ability to sync between its instances. This is not in my expertise area, and possibly not realistically implemented in existing products. You are probably concerned about having a central single point of failure in the system, but you need to keep in mind that the Key Management functionality of the GDS (which is what we are discussing here) isn't actually needed at every moment. You need it to enroll new clients/servers, and then to update their trust lists and certification revocation lists from time to time - which, depending on the security policy (I am guessing now, again it's not my expertise), may be normally done with period of several hours or even considerably longer, but in case of GDS failure the whole system can continue running, for a reasonable amount of time, with what the individual applications already have obtained.

Regards

Hello,

I think the original venue would be better for you to discuss there - not only because it is the right place in terms of scope, but also (and I know it positively) there are people more knowledgeable than me who will answer you.

But anyhow.

GDS is specified in terms of how it communicates with other applications. It has a standardized interface (based on OPC UA as well, look for Part 12 of OPC UA specs) which, among other things, allows other OPC UA applications (both client and servers) to pull certificates from the GDS, push them to GDS (probably not your case), and obtain/update their ow trust lists.

How GDS does that is, intentionally, not standardized. You can have GDS based on Microsoft PKI infrastructure, or something else.
One GDS "type" will be fine to serve all OPC UA servers/clients, even from different vendors.

For this to work, you need to have the right GDS, and the OPC UA applications need to have support for this communication with GDS (instead of using manual certificate configuration, which is usually the default). Not all OPC UA application have that currently, but the market is clearly moving in that direction - because that's about the only way to handle any reasonably complicated installations.

Best regards

Hello,

are you the same poster as here?: opcfoundation.org/forum/opc-ua-standard/opc-ua-certification-windows-pki/#p2222 . - If not, please read it, it has some useful information.

This forum is for our QuickOPC product (client toolkit). QuickOPC uses certificate stores for its own certificate, trusted apps or trusted issuers etc., and by default, it generates it own self-signed certificate using OPC UA certificate generator tool. It also contains functionality to pull the client certificate and trust lists from OPC UA GDS.

In order to use Microsoft PKI with QuickOPC, the preferred way would be o deploy a GDS that integrates with Microsoft PKI, as mentioned in the link above. Other way to do it is to manually (or by other tools) configure QuickOPC to use the right certificates and trust lists and somehow assure that they are properly populated. It ca be done, but would probably be clumsy.

Best regards