===================== SSL/TLS Configuration ===================== All communications between Client Applications and Nucleus are via either WebSockets, or HTTP - and therefore, SSL/TLS can be used to secure the transport. Omniverse Clients can support both SSL/TLS and non-TLS connections: and they detect (and favor) SSL/TLS automatically. Nucleus Enterprise Server, however, **does not itself provide SSL/TLS termination**. This means that even though your deployment can be configured with SSL/TLS, Nucleus itself will not "talk" SSL/TLS: it will still be listening on series of ports, opened as insecure HTTP or WebSocket endpoints. We rely on a *reverse proxy* for SSL/TLS connections. Clients connect to the proxy via SSL/TLS, and it forwards their requests to Nucleus over regular, non-secure connections. We call this proxy an **Ingress Router**. .. image:: tls/prod_nucleus_tls_arch.png :align: center Non-TLS Clients connect to various :ref:`Nucleus Components ` directly - on their ports (i.e., :code:`3009`, :code:`3030`, etc). With SSL/TLS however, Clients connect to a *host* - i.e., :code:`https://my-nucleus.my-company.com` - which is where the Ingress Router would be configured. Ingress Router examines the *path* of the request - and routes (*reverse-proxies*) a Client based on that path. We use the term :code:`Path-Based Routing`, or :code:`PBR`, to define this idea. If a non-SSL Client desires to talk to Nucleus API for example, it would open a connection to :code:`my-nucleus-host.my-company.com`, port :code:`3009`. With SSL/TLS (and PBR), it will instead connect to :code:`https://my-nucleus.my-company.com/omni/api`. The host portion of this URL will lead it to the SSL/TLS termination point (Ingress Router), and path (:code:`/omni/api`) will indicate to Ingress Router that the request should be reverse-proxied to Nucleus's port 3009. (Refer to the diagram above on how paths correlate to ports.) Setting up Nucleus with SSL/TLS ------------------------------- Given the above description, in order to enable SSL/TLS for Nucleus, the following items are needed: * Configure the appropriate network topology * Configure a reverse proxy to act as an Ingress Router * Configure the :doc:`Nucleus Base Stack ` to be aware of the Ingress Router Network Topology ++++++++++++++++ Given that Nucleus itself does not terminate SSL/TLS, if strong security is desired, Nucleus should be placed in a network that is not directly accessible by Clients. A host to run the Ingress Router should be able to freely access Nucleus, and be accessible to Clients on ports :code:`TCP 80` and :code:`TCP 443`. Configuring Ingress Router ++++++++++++++++++++++++++ Any reverse proxy can act as an Ingress Router, provided it supports WebSockets, HTTP, and SSL/TLS. We recommend using `NGINX `_. To make the setup easier, we ship a sample NGINX config file with the Nucleus Enterprise Server :ref:`install artifact `. This sample config file defines each "route" (path - :code:`location{}`) - with the correct reverse proxying rules. A how-to document document for configuring NGINX is also available: :doc:`Configuring SSL/TLS with NGINX ` .. warning:: Omniverse Clients (Apps and Connectors) only support certificates with validated trust chains. Self-signed certificates or certificates with non-matching hostname's will not work properly with Omniverse Clients and will fail without warning. To properly configure a Nucleus Enterprise Server in a secured environment, certificates provided by a well-known Certificate Authority (CA) are required. Single domain certificates, multiple domain (SAN) certificates, and wildcard (*) certificates are fully supported. If your Enterprise relies on an internal PKI (Public Key Infrastructure), this is supported providing the proper trust certificates are deployed to the workstations that connect to Nucleus.