# Understand certificates

> Concept: What certificates do in OPC UA, which stores exist, how client and server check certificates, and how self-signed and signed certificates differ.

> This content was machine translated and may contain errors. [Read in German](https://www.traeger.de/docs/development/opcua/security/certificates)

In OPC UA, client and server identify themselves to each other with certificates. This page explains the basics that apply to client and server alike. To load and store your own certificate, see the [Application certificate](https://www.traeger.de/en/docs/development/opcua/client/configuration#application-certificate) section of the client configuration and the [Application certificate](https://www.traeger.de/en/docs/development/opcua/server/configuration#application-certificate) section of the server configuration. The pages [Secure clients](https://www.traeger.de/en/docs/development/opcua/security/client) and [Secure servers](https://www.traeger.de/en/docs/development/opcua/security/server) describe the settings for production.

## Certificates in OPC UA

Certificates ensure the authenticity and the integrity of client and server applications: they prove that an application is genuine and that it has not been tampered with. For a client or server application, a certificate works like an ID card. This ID card is a file and must be stored somewhere. You decide where the certificates are stored. On Windows, you can hand each certificate over to the system, and Windows then manages its location. Alternatively, you define custom locations, that is, directories.

There are several kinds of certificate locations:

- **Location for application certificates**: This location is also called the Application Certificate Store. It contains only the certificates of the applications that use it as their Application Certificate Store. A client or server application stores its own certificate here.
- **Location for certificates of trusted issuers**: This location is also called the Trusted Issuer Certificate Store. It contains only certificates of certificate authorities that issue other certificates. A client or server application stores the certificates of all issuers here whose certificates it trusts by default.
- **Location for trusted certificates**: This location is also called the Trusted Peer Store. It contains only certificates that are classified as trusted. A client stores the certificates of trusted servers here, and a server stores the certificates of trusted clients.
- **Location for rejected certificates**: This location is also called the Rejected Certificate Store. It contains only certificates that are classified as untrusted. A client stores the certificates of untrusted servers here, and a server stores the certificates of untrusted clients.

Whether the location is in the system or a directory in the file system, the same rules apply. The application trusts certificates in the Trusted Store. It also trusts a certificate that is in none of the stores if the certificate of its issuer is in the Trusted Issuer Store. In that case, it does not copy the certificate to the Trusted Store. The application puts a certificate that it rejects during validation into the Rejected Store. Even a trusted certificate counts as untrusted if it has expired or if the certificate authority cannot confirm the information it contains. Only the application itself or an administrator maintains the Trusted Peer Store. The SDK never adds a certificate there or removes one on its own. A certificate can also become invalid if it is on a Certificate Revocation List (CRL). You can keep this list separately in each store.

A certificate that the client receives from the server, or the server from the client, always starts out as unknown and therefore untrusted. For the application to trust a certificate, the certificate must be declared as trusted. To do this, the certificate of the client goes into the Trusted Store of the server, and the certificate of the server goes into the Trusted Store of the client.

This is how the client handles a server certificate:

1. The client determines the certificate of the server whose endpoint it is to connect to.
2. The client checks the certificate of the server.
   - Is the certificate valid?
     - Has the validity date passed?
     - Is the certificate of the issuer valid?
   - Is the certificate in the Trusted Peer Store?
     - Is it on a Certificate Revocation List (CRL)?
   - Is the certificate in the Rejected Store?
3. If the certificate is trusted, the client connects to the server.

This is how the server handles a client certificate:

1. The server receives the certificate of the client when the connection is established.
2. The server checks the certificate of the client.
   - Is the certificate valid?
     - Has the validity date passed?
     - Is the certificate of the issuer valid?
   - Is the certificate in the Trusted Peer Store?
     - Is it on a Certificate Revocation List (CRL)?
   - Is the certificate in the Rejected Store?
3. If the certificate is trusted, the server accepts the connection of the client and serves it.

If the validation of the certificate of the other side fails, you can extend the validation with your own mechanisms. This way, you can still decide at user level whether the application accepts the certificate.

## Types of certificates

There are two basic types of certificates: self-signed and signed.

A certificate is comparable to a deed. Anyone can issue a deed, and anyone can sign it. What matters is whether the signer really vouches for the correctness of the deed, as a notary does, or whether the signer is the holder of the deed. Deeds of the second kind inspire little confidence, because no recognized legal authority such as a notary vouches for the holder.

The same applies to certificates, because they also carry a digital signature. The signature tells the recipient of a copy of the certificate who vouches for the certificate. The issuer of a certificate always signs it as well. If the issuer of a certificate is also its subject, the certificate is a **self-signed certificate** (subject equals issuer). If issuer and subject differ, it is a signed certificate, also called a simple or normal certificate (subject does not equal issuer).

In OPC UA, certificates mainly authenticate the identity of a specific client or server application. Use signed certificates as application certificates for your own application. If the issuer is also the holder of the certificate, trust this self-signed certificate only if you consider the holder trustworthy. As described above, a signed certificate is signed by its issuer. The issuer certificate must therefore be in the Trusted Issuer Store of the application. If it is missing there, the certificate chain counts as incomplete, and the application does not accept the certificate of the other side. If the issuer certificate is not self-signed itself, the certificate of its issuer must also be in the Trusted Issuer Store.

The section [Validate and trust server certificates](https://www.traeger.de/en/docs/development/opcua/security/client#validate-and-trust-server-certificates) describes how the client checks server certificates and which certificates it accepts. For the server, see the section [Validate and trust client certificates](https://www.traeger.de/en/docs/development/opcua/security/server#validate-and-trust-client-certificates). The page [Users and roles](https://www.traeger.de/en/docs/development/opcua/security/users-roles) describes how a user identifies themselves with a certificate.