TLS Trust Configuration

The TLS Trust configuration bundles the server-side settings for establishing trusted TLS connections. It is found under Settings → TLS Trust configuration and is divided into two areas: the trusted certificates for outbound connections and certificate pinning for Apple enrollment. The TLS Trust configuration is only available in the global organization and applies server-wide to all organizations. Changes in both areas are applied together via Save in the upper area of the page.

Trusted certificates #

Relution accepts these CA certificates in addition to the system’s default trust store when establishing outbound TLS connections. As of Relution 26.5.3 this also applies to the SCEP proxy, and as of Relution 26.5.5 also to the connection to the Salt master and to S3 storage with client-side KMS encryption. Add selects CA certificates that were previously uploaded under Settings → Certificates (see Certificate Management →). The selection dialog only shows certificates marked as a certificate authority (CA); certificate containers such as pfx/p12 are not available for selection. The overview lists Name, Type and the expiry date (Expires) for each entry; selected entries are removed again via Delete.

As of Relution 26.5.8, saving is rejected if a trusted certificate cannot be loaded, does not belong to the global organization or was not uploaded in the certificate management. CA certificates generated by Relution, such as the root certificate of the Built-In CA →, are not permitted as trusted certificates.

Certificates used here as a trusted certificate or as an anchor certificate cannot be deleted in the certificate management as long as they are referenced; likewise, the file and password of such a certificate cannot be replaced. To exchange a certificate, the new certificate is uploaded additionally and selected here, and the old certificate is removed afterwards.

Refresh and status #

Relution rebuilds the list of trusted certificates at server startup, after each save and additionally every hour on each server node. A certificate that cannot be loaded or does not meet the conditions above is left out; the others remain trusted. This also applies to entries saved before Relution 26.5.8.

The state is reported by the tlsTrust health indicator, whose details are shown by the health endpoint on the management port (/actuator/health, port 8099):

• state: IN_SYNC (all configured certificates are trusted), CERTIFICATES_FAILED (individual certificates were left out) or CLEARED (the rebuild failed as a whole, none of the configured certificates is trusted),
• failedCertificates: the UUIDs of the certificates left out.

The indicator never sets the overall status to DOWN, so a load balancer does not take a node out of service because of it. With CERTIFICATES_FAILED or CLEARED, the affected certificates are checked in the certificate management and replaced with an uploaded CA certificate if necessary; further details are written to the server log. The indicator can be disabled with management.health.tlsTrust.enabled: false in application.yml (default: enabled).

Certificate pinning (Apple enrollment) #

When the Enable certificate pinning toggle in the General area is switched on, the MDM server’s TLS connection is validated against selected anchor certificates instead of the system trust store. This makes man-in-the-middle attacks and the use of unauthorized certification authorities more difficult. During the enrollment of Apple devices, pinning is written into the MDM profile and then applies to the device’s entire communication with the MDM server, including check-in. If pinning is disabled, the device validates the connection against the system trust store.

The certificates to be checked are selected in the Anchor certificates area using Add from the CA certificates stored in the certificate management; the overview lists Name, Type and the expiry date (Expires) for each entry. At least one anchor certificate is required to enable pinning. The Require certificate revocation check toggle additionally enforces a check of the certificate revocation status. If Enable certificate pinning is switched off, Relution clears the list of anchor certificates and resets the revocation check; after switching it on again, the anchor certificates must be selected again.

Behavior during enrollment #

When pinning is enabled, the device’s connection to the MDM server is checked against the selected anchor certificates during enrollment. If the server’s TLS certificate chain can be traced back to one of the anchor certificates, enrollment succeeds. This check also applies to the subsequent MDM communication of the enrolled device. If it differs, the connection is rejected and enrollment fails.

If pinning is switched on but no anchor certificate is configured or can be loaded, Relution generates the MDM profiles without pinning.

Devices with an operating system version below the minimum required for pinning continue to be enrolled without pinning; enrollment remains functional there.

Anchor certificate notifications #

Relution checks the pinned anchor certificates every hour and after each save and reports problems in the notification center so that devices being locked out can be prevented early. The notifications are received by users of the global organization who are allowed to view the TLS Trust configuration. Reported issues include:

• an anchor certificate that expires in less than 90 days or has already expired,
• an anchor certificate that cannot be loaded or is not a CA certificate,
• ineffective pinning, for example when no anchor certificate is configured or none matches the server’s TLS certificate chain.