Create an mTLS-protected TCP share

Learn how to create an mTLS-protected TCP share in Frontdoor.

note

• To create an OAuth-protected share, you must use a custom frontend.
• To create a public share, see our getting started guide.

Steps

Frontdoor console

1. From the Frontdoor console, click Shares in the left-hand menu.

2. Click the + icon to create a new share.

3. Fill in the share fields:

   • Name: Enter a name used to access the share; must be alphanumeric and start with a letter.
   • Hosting Frontdoor agent: Select the agent you created.
   • Share type: Select TCP. See Shares overview for more info.
   • Target host:port: Enter the host and port of the application or service you want to share; must be accessible from the agent you selected.
   • Ingress port: Enter the port on which Frontdoor will accept incoming connections for this share.

4. Under Certificate Authentication, select System Generated Certificate or Client Certificate.

   For System Generated Certificate, fill in the fields:

   • Allowed subjects: Enter a comma-separated list of allowed subject names for client certificates.
     • Example: CN=service-account-1, O=MyCompany
   • Allowed common name prefixes: Enter a comma-separated list of allowed common name prefixes for client certificates.
   • • Example: service-account-;frontdoor-access-;example-
   • Organizational unit: Enter a comma-separated list of allowed organizational units for client certificates.

   For Client Certificate, select the client certificate you uploaded.

5. Click Create share.

   You're returned to the Frontdoor Shares page, where you can see your ingress address in host:port format under the Access column. It may take a few minutes for the share to become active.

Command-line interface

Example A: Intermediate CA with assurances (OU and/or CN prefix)

Each Frontdoor has a built-in intermediate CA that is used to sign client certificates. This example shows how to create a TCP share that requires a client certificate issued by the built-in intermediate CA and enforces assurances:

1. Create a TCP share that trusts that intermediate and enforces assurances:

   curl -s -X POST \
     -H "Authorization: Bearer $TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
           "type": "tcp",
           "name": "svc-ssh",
           "envZId": "ijcrWb-ZOq",
           "ingressPort": 2142,
           "target": "tcp://ssh.internal.local:22",
           "requiredOrganizationalUnit": "engineering",
           "allowedCommonNamePrefixes": [ "svc-" ]
           "useIntermediateCertificate": true
         }' \
     "https://gateway.production.netfoundry.io/frontdoor/$FRONTDOOR_ID/shares"

   Only client certificates issued by the intermediate AND matching OU=engineering AND with CN starting with svc- will be accepted. allowedSubjects, allowedCommonNamePrefixes, and requiredOrganizationalUnit are optional fields.

2. Connect using a leaf certificate issued by that intermediate:

   openssl s_client -connect your-tcp-endpoint.example.com:2142 \
     -cert client.crt -key client.key -quiet

tip

For best interoperability, include the full client chain in client.crt (leaf first, then any intermediates). Frontdoor validates the presented chain up to the uploaded intermediate.

Example B: Pinned client certificate

Accept exactly one client certificate by pinning to a single client certificate. This is useful for highly restricted access.

1. Create the TCP share and pin to the client certificate:

   curl -s -X POST \
     -H "Authorization: Bearer $TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
           "type": "tcp",
           "name": "db-admin",
           "envZId": "ijcrWb-ZOq",
           "ingressPort": 2155,
           "target": "tcp://db.internal.local:5432",
           "clientCertificateId": "fdkjasd74h"
         }' \
     "https://gateway.production.netfoundry.io/frontdoor/$FRONTDOOR_ID/shares"

   Only the certificate created in the client certificate management section will be accepted.

2. Connect with the pinned certificate:

   openssl s_client -connect your-tcp-endpoint.example.com:2155 \
     -cert client.crt -key client.key -quiet

note

Client certificate pinning uses the exact certificate. If you re-issue the certificate it will stop working.