Observer OMS : Observer Management Server (OMS) : Understanding OMS : Understanding the certificate trust model
Understanding the certificate trust model
The certificate trust model allows Observer Platform products to securely communicate using TLS encryption. It also provides resistance to man-in-the-middle attacks by requiring administrator intervention when a known certificate has changed.
All product-to-product communication is encrypted by default using SHA2. A web of trust between Observer Platform products is created by requiring certificates from each participating software application. The main benefit is that this ensures encryption of communication between all parts of the Observer Platform.
Each software application owns a unique certificate. This certificate is automatically created during the first installation of an Observer Platform application, for example, Apex. The unique application certificate is labeled Local when viewed from inside that software application. Upgrading to newer software versions does not create a new certificate, so no certificate maintenance is typically needed. However, uninstalling and reinstalling (fresh installs) creates a new certificate. The new certificate will be automatically rejected by other products that had a pre-existing association with the asset ID of the reinstalled software.
The first time two products communicate, each checks to see if they have the certificate for the asset ID of the other software application. If they do not, then certificates are exchanged, marked Trusted, and associated with the asset ID of the participating device. This enables the “easy configuration” model. After an association is made, each application will expect to see the same certificate (to remain trusted) when communicating.
Note: Prior to version 17 of the Observer Platform, encryption was available but not enabled by default. This has changed to become the default out-of-the-box behavior in Observer Platform version 17 and later, and it also uses a stronger cipher suite.
Certificates are automatically rejected when trust cannot be verified. If a certificate is associated to an asset ID, and an inbound connection from that asset (determined by the asset ID) occurs using a different certificate, the administrator must inspect and manually accept the certificate because the certificate is in a Rejected state. A rejected certificate breaks the trust model, so any offending device(s) and software are banned from product-to-product communication until an administrator investigates and accepts the certificate.
Certificates can be manually rejected by administrators. In the event that product-to-product communication must be immediately severed because of an imminent threat or other security risk, an administrator can manually reject certificates.