Securing communication with TLS

Enterprise DC/OS Preview Updated: April 18, 2017

In permissive and strict security modes, your DC/OS Certificate Authority signs the TLS certificates and provisions them to systemd-started services during the bootstrap sequence. This accomplishes encrypted communications with no manual intervention. Each DC/OS cluster has its own DC/OS Certificate Authority and a unique root certificate to protect DC/OS clusters from each other.

Because your DC/OS Certificate Authority does not appear in any lists of trusted certificate authorities, requests coming in from outside the cluster, such as from a browser or curl, will result in warning messages.

To establish trusted communications with your DC/OS cluster and stop the warning messages:

  1. Obtain the root certificate of your DC/OS CA.

  2. Perform one of the following.

    • Manually add your DC/OS Certificate Authority as a trusted authority in browser, DC/OS CLI, curl commands, and other clients.

    • Set up a proxy between the Admin Router and user agent requests coming in from outside of the cluster.

Configuring HAProxy in Front of Admin Router

You can use HAProxy to set up an HTTP proxy in front of the DC/OS Admin Router. For example, this can be useful if you want to present a custom server certificate to user agents co...

Downloading the Root Certificate

To ensure that you are communicating with your DC/OS cluster and not another party, you must download the root certificate of your DC/OS certificate authority (CA) using one of the...

Certificate Authority API

The Certificate Authority API allows you to view the TLS certificates used by Enterprise DC/OS, create Certificate Signing Requests (CSRs), and have the DC/OS CA sign CSRs.