--- title: "Understanding network dependencies for LUSID and Luminesce" slug: "understanding-network-dependencies-for-lusid-and-luminesce" updated: 2025-03-24T16:24:31Z published: 2025-03-24T16:24:31Z canonical: "support.lusid.com/understanding-network-dependencies-for-lusid-and-luminesce" --- > ## Documentation Index > Fetch the complete documentation index at: https://support.lusid.com/llms.txt > Use this file to discover all available pages before exploring further. # Understanding network dependencies for LUSID and Luminesce To run any [Luminesce provider](/v1/docs/understanding-the-luminesce-platform-architecture) within your infrastructure, you must make certain types of connectivity available to the application. IP, domain and URL allow lists tell your network servers and security tools to allow access to the network destinations you add to the list. If your server, network or security tool policies… - Allow all outbound HTTP and HTTPS communication to any IP address, domain or URL: You do not need to make any changes. - Deny access to most or all external endpoints: You must update the relevant allow lists using the information in this article. > [!NOTE] > Important > > When checking and configuring policies for access as described in the following sections, ensure you verify all systems that control network traffic between the application and the internet, such as: > > - Network Firewalls > - Device level firewalls > - Security software on the server/workstation > - Web proxies with filtering capabilities > - Security tooling integrated with centralised DNS infrastructure. ## Ports The [FINBOURNE APIs and web applications](/v1/docs/understanding-all-the-applications-in-the-finbourne-platform) operate using TLS for all communication. You must ensure port 443 is allow-listed for all domains and IP addresses in this article unless otherwise noted. To run Luminesce providers, you must additionally permit traffic over port 5671 for the `lusid.com` domains and subdomains listed in the [next section](/v1/docs/understanding-network-dependencies#lusid-domains). > [!NOTE] > **Note:** Port 5671 only requires you to allow outgoing connections. > > > > If you cannot allow outgoing connections, Luminesce has built-in functionality (“Communicate to AMQP over the Hutch-Proxy”) to route that same traffic over port 443. Note this functionality may impact performance and reliability due to the involvement of another service. > > > > To use this functionality, add `--viaProxy` to the command line options when starting the providers. This may require some additional configuration on the Luminesce server-side when first enabled. ## LUSID domains You must ensure your firewalls permit bidirectional traffic for the IPs associated with the following domains: - `<your-domain>.lusid.com` - `<your-domain>.identity.lusid.com` If you’re only restricting access to applications servers, the above domains are sufficient. If your restrictions apply to all desktop users, the following additional domains must be permitted: - `support.lusid.com` - `mixpanel.com` - `*.mixpanel.com` - `status.lusid.com` - `uptime.lusid.com` ## Okta domains The [FINBOURNE ecosystem of applications](/v1/docs/understanding-all-the-applications-in-the-finbourne-platform) uses Okta to power identity features. It is therefore necessary to permit traffic to Okta servers for activities like authentication: - `lusid-<your-domain>.okta.com` If you’re restricting access only to applications servers, the above domain is sufficient. If your restrictions apply to all desktop users, you must setup further configuration to support the full Okta experience. For full details of the required domains, [see the Okta documentation](https://help.okta.com/en-us/content/topics/security/ip-address-allow-listing.htm#Implementation%20Details). ## Certificate revocation domains Because all traffic is secured using TLS, those certificates support Certificate Revocation Lists (CRL), Online Certificate Status Protocol (OCSP), or both. The certificates contain CRL Distribution Points URIs and/or OCSP URIs. These are checked during connection as part of the standard TLS security controls. As such, you must make the CRL/OCSP URIs available to the applications. You must also check any intermediate certificates between the server certificate (end-entity certificate or leaf-certificate) and a trusted root certificate (trust anchor) for CRL/OCSP URIs. For each of the CRL/OCSP URIs present on the certificates, there may be additional redirect chains through DNS Records (for example DNS CNAME or ALIAS records) or HTTP redirection. These CRL/OCSP URIs and their potential redirects are outside of FINBOURNE’s control. The CRL/OCSP domains for the LUSID and Luminesce certificates are as follows: - `*.o.lencr.org` - `o.lencr.edgesuite.net` - `a1887.dscq.akamai.net` The CRL domains for the Okta certificates are as follows: - `ocsp.digicert.com` - `ocsp.edge.digicert.com` - `fp2e7a.wpc.2be4.phicdn.net` - `fp2e7a.wpc.phicdn.net` - `crl3.digicert.com` - `crl4.digicert.com` - `crl.edge.digicert.com` You can perform the diagnostic steps in the [next section](/v1/docs/understanding-network-dependencies#diagnosing-common-configuration-issues) to check a connection should work and diagnose some common configuration issues. ## Diagnosing common configuration issues ### Step 1: Extract CRL/OCSP URIs from the server certificates Run the following commands to extract CRL/OCSP URIs from the server certificates: - Your LUSID domain: ```shell echo | openssl s_client -connect .lusid.com:443 -servername .lusid.com 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -noout -ocsp_uri ``` A response is as follows: ```shell http://r10.o.lencr.org ``` - Okta OCSP: ```shell echo | openssl s_client -connect lusid-.okta.com:443 -servername lusid-.okta.com 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -noout -ocsp_uri ``` A response is as follows: ```shell http://ocsp.digicert.com ``` - Okta CRL: ```shell echo | openssl s_client -connect lusid-.okta.com:443 -servername lusid-.okta.com 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -noout -text | grep -A4 "CRL Distribution Points" ``` A response is as follows: ```shell X509v3 CRL Distribution Points: Full Name: URI:http://crl3.digicert.com/DigiCertTLSRSASHA2562020CA1-4.crl Full Name: URI:http://crl4.digicert.com/DigiCertTLSRSASHA2562020CA1-4.crl ``` - An entire certificate chain, including intermediate certificates: ```shell echo | openssl s_client -showcerts -connect .lusid.com:443 -servername .lusid.com 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > certs.pem ``` Note the following: You must investigate each certificate in the chain for CRL and OCSP URIs. - The chain contains the server certificate (end-entity or leaf certificate) and intermediate certificates. - The leaf certificate is at depth 0 in the chain. - Intermediate certificates are at depth 1, 2, 3, and so on, up to a trusted RootCA. - The RootCA, also known as a trust anchor, is not included in the chain presented by the server. ### Step 2: Check for redirects and consider additions to allow list Once extracted, you can check the CRL and OCSP URIs for the following types of redirection: > [!NOTE] > Note > > The OCSP/CRL URIs and redirects are outside of FINBOURNE’s control. Depending on your security controls, you *may* need to allow-list each item in the response to resolve your configuration issues. [Read more.](/v1/docs/understanding-network-dependencies#certificate-revocation-domains) - Any DNS-based redirection. For example: - ```shell host r10.o.lencr.org ``` A response is as follows: ```shell r10.o.lencr.org is an alias for o.lencr.edgesuite.net. o.lencr.edgesuite.net is an alias for a1887.dscq.akamai.net. a1887.dscq.akamai.net has address 104.86.110.235 a1887.dscq.akamai.net has address 2.18.66.17 a1887.dscq.akamai.net has IPv6 address 2a02:26f0:1c80:4::212:be4a a1887.dscq.akamai.net has IPv6 address 2a02:26f0:1c80:4::212:be49 ``` - ```shell host ocsp.digicert.com ``` A response is as follows: ```shell ocsp.digicert.com is an alias for ocsp.edge.digicert.com. ocsp.edge.digicert.com is an alias for fp2e7a.wpc.2be4.phicdn.net. fp2e7a.wpc.2be4.phicdn.net is an alias for fp2e7a.wpc.phicdn.net. fp2e7a.wpc.phicdn.net has address 192.229.221.95 fp2e7a.wpc.phicdn.net has IPv6 address 2606:2800:233:fa02:67b:9ff6:6107:833 ``` - ```shell host crl3.digicert.com ``` A response is as follows: ```shell crl3.digicert.com is an alias for crl.edge.digicert.com. crl.edge.digicert.com is an alias for fp2e7a.wpc.2be4.phicdn.net. fp2e7a.wpc.2be4.phicdn.net is an alias for fp2e7a.wpc.phicdn.net. fp2e7a.wpc.phicdn.net has address 192.229.221.95 fp2e7a.wpc.phicdn.net has IPv6 address 2606:2800:233:fa02:67b:9ff6:6107:833 ``` - ```shell host crl4.digicert.com ``` A response is as follows: ```shell crl4.digicert.com is an alias for crl.edge.digicert.com. crl.edge.digicert.com is an alias for fp2e7a.wpc.2be4.phicdn.net. fp2e7a.wpc.2be4.phicdn.net is an alias for fp2e7a.wpc.phicdn.net. fp2e7a.wpc.phicdn.net has address 192.229.221.95 fp2e7a.wpc.phicdn.net has IPv6 address 2606:2800:233:fa02:67b:9ff6:6107:833 ``` - Any HTTP-based redirection. You can run the following commands: ```shell curl --silent -iL http://r10.o.lencr.org | egrep '^Location' curl --silent -iL http://ocsp.digicert.com | egrep '^Location' curl --silent –iL http://crl3.digicert.com/DigiCertTLSRSASHA2562020CA1-4.crl | egrep '^Location' curl --silent -iL http://crl4.digicert.com/DigiCertTLSRSASHA2562020CA1-4.crl | egrep '^Location' ```