{"data":{"slug":"opc-ua-certificate-management","title":"OPC UA Certificate and Trust Management (GDS)","summary":"OPC UA's security model is built on X.509 certificates: every application instance has an application certificate, and trust is expressed by which certificates…","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/opc-ua-certificate-management","markdown_url":"https://wiki.aspotomasyon.com/article/opc-ua-certificate-management.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-ua-certificate-management","published":"2026-08-11T13:05:19+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":4,"word_count":804,"image":"https://wiki.aspotomasyon.com/assets/social/opc-ua-certificate-management-a27cee5b0edc.png","html":"<p>OPC UA's security model is built on X.509 certificates: every application instance has an application certificate, and trust is expressed by which certificates are installed in each application's trust store. This design is robust — but it puts the burden of certificate lifecycle management on the integrator. In a plant with dozens of clients and servers, manual certificate handling becomes the dominant OPC UA operations cost. The standard's answer is the <strong>Global Discovery Server (GDS)</strong> with certificate push management, defined in OPC 10000-12 (Discovery) and OPC 10000-21 (Part 21: GDS).</p><figure class=\"article-figure\"><img src=\"https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-context.svg\" width=\"1100\" height=\"460\" loading=\"lazy\" decoding=\"async\" alt=\"A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do.\"><figcaption>A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do. <a href=\"https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-context.svg\" target=\"_blank\" rel=\"noopener\">View full size</a></figcaption></figure>\n\n<h2 id=\"how-trust-works-in-opc-ua\">How Trust Works in OPC UA</h2>\n\n<p>When two OPC UA applications connect with security enabled:</p>\n\n<ol>\n  <li>Each side presents its application certificate during the handshake.</li>\n  <li>Each side validates the peer's certificate: signature chain, validity period, and — crucially — membership in the local trust store (trusted list or trusted issuer CA).</li>\n  <li>If validation fails, the connection is rejected unless the receiving side has an explicit exception (e.g., trust-on-first-use is enabled in that application).</li>\n</ol>\n\n<p>The trust model supports two styles:</p>\n\n<ul>\n  <li><strong>Direct trust</strong> — each peer's exact certificate is in the trusted list (simple, brittle: every renewal touches every peer).</li>\n  <li><strong>CA-based trust</strong> — applications trust the CA (or intermediate) that issues peer certificates (scalable: renewals work without touching peers, as long as the CA stays valid).</li>\n</ul>\n\n<p>CA-based trust is the right architecture for anything beyond a handful of permanently installed applications.</p>\n\n<h2 id=\"certificate-lifecycle-in-practice\">Certificate Lifecycle in Practice</h2>\n\n<p>An application certificate has a lifecycle that someone must operate:</p>\n\n<ul>\n  <li><strong>Creation</strong> — generated with a proper key length (RSA 2048/3072 or ECC P-256), a meaningful subject, and a SubjectAltName URI matching the server's endpoint hostname.</li>\n  <li><strong>Distribution</strong> — the certificate is exported to every peer's trust store (and the CA certificate to trusted-issuer stores).</li>\n  <li><strong>Renewal</strong> — before expiry (or immediately after key compromise), a new certificate is issued; with CA-based trust, distribution is limited to updating the application instance itself.</li>\n  <li><strong>Revocation</strong> — for compromised keys, the CA publishes a CRL; applications supporting revocation check it — enable and test this, most deployments never do.</li>\n  <li><strong>Retirement</strong> — remove expired certificates from trust stores; accumulated dead certificates silently broaden trust.</li>\n</ul>\n\n<h2 id=\"the-gds-and-push-management\">The GDS and Push Management</h2>\n\n<p>The GDS centralizes these operations. It provides:</p>\n\n<ul>\n  <li><strong>Discovery</strong> — applications register with the GDS; clients can query \"which servers are available?\" (LDAP-style and OPC UA style registration).</li>\n  <li><strong>Certificate management</strong> — the GDS issues certificates from a configured CA on behalf of applications (with offline approval workflow), and distributes trust lists.</li>\n  <li><strong>Push management (Part 21)</strong> — the GDS pushes updated certificates and trust lists to registered applications over a secure channel, so a plant-wide trust update is one operation instead of a maintenance window per machine.</li>\n</ul>\n\n<p>Deploying a GDS (e.g., the OPC Foundation's reference GDS, or vendor implementations integrated into Kepware, Ignition, and platform products) requires planning: the GDS itself is a high-value target, so it belongs in its own security zone with strong access control and auditing.</p>\n\n<h2 id=\"practical-deployment-guidance\">Practical Deployment Guidance</h2>\n\n<ol>\n  <li>Start with a clear trust policy: what is allowed to connect, from where, and with which security policy (minimum: Basic256Sha256; prefer the newer Aes128Sha256RsaOaep where supported).</li>\n  <li>Use CA-based trust wherever the software supports it; keep direct trust only for legacy devices that cannot be updated.</li>\n  <li>Give every application a certificate with a stable identity: hostname/URI, role, and owner in the subject fields.</li>\n  <li>Automate renewal with a GDS or a scheduled certificate task; track expiry dates in the asset register — expired certificates are the #1 cause of mystery connection failures after maintenance windows.</li>\n  <li>Enable and test revocation, at least for the CA you control.</li>\n  <li>Document the trust topology (who trusts whom, which CA issues what) as a diagram in the OT documentation set, and review it annually.</li>\n</ol>\n\n<h2 id=\"summary\">Summary</h2>\n\n<p>OPC UA security is only as good as the certificate lifecycle behind it. Design for CA-based trust, operate the lifecycle deliberately (create, distribute, renew, revoke, retire), and centralize with a GDS when the fleet grows beyond manual reach. Certificates are not an IT nuisance — they are the access control mechanism of the OT data plane, and they deserve the same rigor as passwords.</p><section class=\"engineering-check\"><h2 id=\"apply-this-to-your-project\">Apply this to your project</h2><ul><li>Record the endpoint, supported security policies, application identity, certificate expiry, and user permissions.</li><li>Verify the value, engineering unit, StatusCode, and source timestamp together at the receiving application.</li><li>Test disconnection and recovery with representative subscriptions; preserve evidence of any data gaps or repeated values.</li></ul><p><a href=\"https://wiki.aspotomasyon.com/guides\">Follow an ASP project guide</a> to connect the fundamentals with implementation and acceptance.</p></section><figure class=\"article-figure\"><img src=\"https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-review.svg\" width=\"1100\" height=\"460\" loading=\"lazy\" decoding=\"async\" alt=\"Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration.\"><figcaption>Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration. <a href=\"https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-review.svg\" target=\"_blank\" rel=\"noopener\">View full size</a></figcaption></figure><h2 id=\"primary-references-and-further-reading\">Primary references and further reading</h2><p>Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.</p><ul><li><a href=\"https://reference.opcfoundation.org/specs/OPC-10000-4/\" rel=\"noopener noreferrer\" target=\"_blank\">OPC Foundation — OPC UA Part 4: Services</a></li><li><a href=\"https://reference.opcfoundation.org/specs/OPC-10000-2/\" rel=\"noopener noreferrer\" target=\"_blank\">OPC Foundation — OPC UA Part 2: Security Model</a></li></ul><!-- asp-editorial-202609 -->","markdown":"# OPC UA Certificate and Trust Management (GDS)\n\n> OPC UA's security model is built on X.509 certificates: every application instance has an application certificate, and trust is expressed by which certificates…\n\n- Canonical URL: https://wiki.aspotomasyon.com/article/opc-ua-certificate-management\n- Publisher: ASP OTOMASYON A.Ş. (ASP OTOMASYON Wiki)\n- Category: OPC Solutions\n- Published: 2026-08-11 · Updated: 2026-09-13\n- Reading time: 4 min · Language: English\n\nOPC UA's security model is built on X.509 certificates: every application instance has an application certificate, and trust is expressed by which certificates are installed in each application's trust store. This design is robust — but it puts the burden of certificate lifecycle management on the integrator. In a plant with dozens of clients and servers, manual certificate handling becomes the dominant OPC UA operations cost. The standard's answer is the **Global Discovery Server (GDS)** with certificate push management, defined in OPC 10000-12 (Discovery) and OPC 10000-21 (Part 21: GDS).\n\n![A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do.](https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-context.svg)\n\n*A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do.*\n\n## How Trust Works in OPC UA\n\nWhen two OPC UA applications connect with security enabled:\n\n1. Each side presents its application certificate during the handshake.\n2. Each side validates the peer's certificate: signature chain, validity period, and — crucially — membership in the local trust store (trusted list or trusted issuer CA).\n3. If validation fails, the connection is rejected unless the receiving side has an explicit exception (e.g., trust-on-first-use is enabled in that application).\n\nThe trust model supports two styles:\n\n- **Direct trust** — each peer's exact certificate is in the trusted list (simple, brittle: every renewal touches every peer).\n- **CA-based trust** — applications trust the CA (or intermediate) that issues peer certificates (scalable: renewals work without touching peers, as long as the CA stays valid).\n\nCA-based trust is the right architecture for anything beyond a handful of permanently installed applications.\n\n## Certificate Lifecycle in Practice\n\nAn application certificate has a lifecycle that someone must operate:\n\n- **Creation** — generated with a proper key length (RSA 2048/3072 or ECC P-256), a meaningful subject, and a SubjectAltName URI matching the server's endpoint hostname.\n- **Distribution** — the certificate is exported to every peer's trust store (and the CA certificate to trusted-issuer stores).\n- **Renewal** — before expiry (or immediately after key compromise), a new certificate is issued; with CA-based trust, distribution is limited to updating the application instance itself.\n- **Revocation** — for compromised keys, the CA publishes a CRL; applications supporting revocation check it — enable and test this, most deployments never do.\n- **Retirement** — remove expired certificates from trust stores; accumulated dead certificates silently broaden trust.\n\n## The GDS and Push Management\n\nThe GDS centralizes these operations. It provides:\n\n- **Discovery** — applications register with the GDS; clients can query \"which servers are available?\" (LDAP-style and OPC UA style registration).\n- **Certificate management** — the GDS issues certificates from a configured CA on behalf of applications (with offline approval workflow), and distributes trust lists.\n- **Push management (Part 21)** — the GDS pushes updated certificates and trust lists to registered applications over a secure channel, so a plant-wide trust update is one operation instead of a maintenance window per machine.\n\nDeploying a GDS (e.g., the OPC Foundation's reference GDS, or vendor implementations integrated into Kepware, Ignition, and platform products) requires planning: the GDS itself is a high-value target, so it belongs in its own security zone with strong access control and auditing.\n\n## Practical Deployment Guidance\n\n1. Start with a clear trust policy: what is allowed to connect, from where, and with which security policy (minimum: Basic256Sha256; prefer the newer Aes128Sha256RsaOaep where supported).\n2. Use CA-based trust wherever the software supports it; keep direct trust only for legacy devices that cannot be updated.\n3. Give every application a certificate with a stable identity: hostname/URI, role, and owner in the subject fields.\n4. Automate renewal with a GDS or a scheduled certificate task; track expiry dates in the asset register — expired certificates are the #1 cause of mystery connection failures after maintenance windows.\n5. Enable and test revocation, at least for the CA you control.\n6. Document the trust topology (who trusts whom, which CA issues what) as a diagram in the OT documentation set, and review it annually.\n\n## Summary\n\nOPC UA security is only as good as the certificate lifecycle behind it. Design for CA-based trust, operate the lifecycle deliberately (create, distribute, renew, revoke, retire), and centralize with a GDS when the fleet grows beyond manual reach. Certificates are not an IT nuisance — they are the access control mechanism of the OT data plane, and they deserve the same rigor as passwords.\n\n## Apply this to your project\n\n- Record the endpoint, supported security policies, application identity, certificate expiry, and user permissions.\n- Verify the value, engineering unit, StatusCode, and source timestamp together at the receiving application.\n- Test disconnection and recovery with representative subscriptions; preserve evidence of any data gaps or repeated values.\n\n[Follow an ASP project guide](https://wiki.aspotomasyon.com/guides) to connect the fundamentals with implementation and acceptance.\n\n![Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration.](https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-review.svg)\n\n*Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration.*\n\n## Primary references and further reading\n\nUse the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.\n\n- [OPC Foundation — OPC UA Part 4: Services](https://reference.opcfoundation.org/specs/OPC-10000-4/)\n- [OPC Foundation — OPC UA Part 2: Security Model](https://reference.opcfoundation.org/specs/OPC-10000-2/)\n\n---\n\nCite the canonical article: https://wiki.aspotomasyon.com/article/opc-ua-certificate-management (OPC UA Certificate and Trust Management (GDS), ASP OTOMASYON, updated 2026-09-13).\n","headings":[{"id":"how-trust-works-in-opc-ua","title":"How Trust Works in OPC UA"},{"id":"certificate-lifecycle-in-practice","title":"Certificate Lifecycle in Practice"},{"id":"the-gds-and-push-management","title":"The GDS and Push Management"},{"id":"practical-deployment-guidance","title":"Practical Deployment Guidance"},{"id":"summary","title":"Summary"},{"id":"apply-this-to-your-project","title":"Apply this to your project"},{"id":"primary-references-and-further-reading","title":"Primary references and further reading"}],"faq":[],"references":[{"name":"OPC Foundation — OPC UA Part 4: Services","url":"https://reference.opcfoundation.org/specs/OPC-10000-4/"},{"name":"OPC Foundation — OPC UA Part 2: Security Model","url":"https://reference.opcfoundation.org/specs/OPC-10000-2/"}],"related":[{"slug":"opc-ua-discovery-lds-gds","title":"OPC UA Discovery: LDS, LDS-ME, and Global Discovery Server Explained","summary":"OPC UA discovery lets clients find servers and their endpoints through a local discovery server on each host, a multicast extension, or a global discovery…","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/opc-ua-discovery-lds-gds","markdown_url":"https://wiki.aspotomasyon.com/article/opc-ua-discovery-lds-gds.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-ua-discovery-lds-gds","published":"2026-10-11T11:46:21+00:00","modified":"2026-10-11T11:46:21+00:00","reading_minutes":9,"word_count":1844,"image":"https://wiki.aspotomasyon.com/assets/social/opc-ua-discovery-lds-gds-c305c85ac14a.png"},{"slug":"opc-ua-connection-troubleshooting","title":"OPC UA Connection Troubleshooting and Performance Tuning","summary":"OPC UA is the most common integration fabric in modern industrial systems, and most integration projects eventually hit the same wall: a client that cannot…","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/opc-ua-connection-troubleshooting","markdown_url":"https://wiki.aspotomasyon.com/article/opc-ua-connection-troubleshooting.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-ua-connection-troubleshooting","published":"2026-08-11T13:05:19+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":5,"word_count":916,"image":"https://wiki.aspotomasyon.com/assets/social/opc-ua-connection-troubleshooting-35c3173b9013.png"},{"slug":"opc-ua-pub-sub-configuration","title":"OPC UA Pub/Sub Configuration and Deployment Guide","summary":"OPC UA Pub/Sub extends the traditional client-server OPC UA model with a publish-subscribe communication pattern.","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/opc-ua-pub-sub-configuration","markdown_url":"https://wiki.aspotomasyon.com/article/opc-ua-pub-sub-configuration.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-ua-pub-sub-configuration","published":"2026-05-13T11:58:29+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":6,"word_count":1147,"image":"https://wiki.aspotomasyon.com/assets/social/opc-ua-pub-sub-configuration-33cfd0c96572.png"},{"slug":"opc-ua-certificate-renewal-plan","title":"OPC UA Certificate Renewal Without Surprise Connection Failures","summary":"OPC UA certificate renewal is an operational change that can affect every client trusting an application.","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/opc-ua-certificate-renewal-plan","markdown_url":"https://wiki.aspotomasyon.com/article/opc-ua-certificate-renewal-plan.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-ua-certificate-renewal-plan","published":"2026-09-13T11:07:23+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":2,"word_count":355,"image":"https://wiki.aspotomasyon.com/assets/social/opc-ua-certificate-renewal-plan-b7aec4ef864a.png"}],"citation":"ASP OTOMASYON. OPC UA Certificate and Trust Management (GDS). Updated 2026-09-13. https://wiki.aspotomasyon.com/article/opc-ua-certificate-management"}}