Understanding network dependencies for LUSID and Luminesce

To run any Luminesce provider 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.

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 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.

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 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.

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 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:

    echo | openssl s_client -connect <your-domain>.lusid.com:443 -servername <your-domain>.lusid.com 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -noout -ocsp_uri

    A response is as follows:

    http://r10.o.lencr.org

  • Okta OCSP:

    echo | openssl s_client -connect lusid-<your-domain>.okta.com:443 -servername lusid-<your-domain>.okta.com 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -noout -ocsp_uri

    A response is as follows:

    http://ocsp.digicert.com

  • Okta CRL:

    echo | openssl s_client -connect lusid-<your-domain>.okta.com:443 -servername lusid-<your-domain>.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:

    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:

    echo | openssl s_client -showcerts -connect <your-domain>.lusid.com:443 -servername <your-domain>.lusid.com 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > certs.pem

    Note the following:

    • 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.

    You must investigate each certificate in the chain for CRL and OCSP URIs.

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

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.

  • Any DNS-based redirection. For example:

    • host r10.o.lencr.org

      A response is as follows:

      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
    • host ocsp.digicert.com

      A response is as follows:

      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
    • host crl3.digicert.com

      A response is as follows:

      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
    • host crl4.digicert.com

      A response is as follows:

      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:

    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'