---
updatedAt: 2026-08-07T08:29:52.000Z
agentTools:
  siteIndex: https://docs.jfrog.com/llms.txt
  projectIndex: https://docs.jfrog.com/installation/llms.txt
---

# Establish TLS in Artifactory and JFrog Platform

Enable TLS encryption between JFrog Platform nodes: configure Access CA, certificates, Kubernetes service SANs, and Nginx.

<Callout icon="❗️" theme="error">
  **JFrog Recommends Enabling TLS at Nginx Level**

  If you want to terminate TLS at the load balancer level, and send HTTP requests to Artifactory, you do not need to enable TLS within the JFrog Platform. Instead, use Nginx to offload HTTPS requests to Artifactory using HTTP, and you can configure Nginx to use your own custom certificate and key. For more information, see [Nginx with TLS](#nginx-with-tls).
</Callout>

HTTPS encrypts communication using Transport Layer Security (TLS). By default, TLS between JFrog Platform nodes is disabled. When TLS is enabled, JFrog Access acts as the Certificate Authority (CA), signing TLS certificates and enabling encrypted communication between JFrog Artifactory and other JFrog products. For more information, see [TLS on JFrog Platform](set-tls-on-the-jfrog-platform).

When deploying the JFrog Platform using Helm in a Kubernetes (K8s) cluster, all products should connect to JFrog Artifactory via its Kubernetes service. To ensure proper TLS validation, the TLS certificate issued by JFrog Access and used by the JFrog Router must include the *Service URL* in the **Subject Alternative Name (SAN)** field.

Kubernetes services for JFrog products follow a specific naming convention based on the Helm release name and product name. For example, if the Helm release is `jfrog-platform`, the generated service names will be as follows:

* **Artifactory**: `jfrog-platform-artifactory`
* **Xray**: `jfrog-platform-xray`
* **General**: `jfrog-platform-product`

You must add the full Artifactory service name as a SAN in the Access-generated certificate.

## Enable TLS in Artifactory

1. In Artifactory's `values.yaml` file, set `security.tls` to `true` under the `accessConfig` section.

   ```yaml
   access:
     accessConfig:
       security:
         tls: true
   ```

2. Add the Artifactory service name as a SAN to the Access certificate. Use Helm templating to automate this and avoid hardcoding the release name. For example:

   ```yaml
   access:
     accessConfig:
       security:
         tls: true
         tls-subject-alternative-names:
           - '{{ template "artifactory.fullname" . }}'
   ```

   This template is defined in the <a href="https://github.com/jfrog/charts/blob/master/stable/artifactory/templates/_helpers.tpl" target="_blank">\_helpers.tpl</a> file and resolves to the <a href="https://github.com/jfrog/charts/blob/master/stable/artifactory/templates/artifactory-service.yaml" target="_blank">Artifactory Service name</a>, eliminating the need for hardcoded values.

   With this configuration, Router and Access accept only HTTPS connections from external sources, including other JFrog products connecting via the service name. In this example, the release name is `jfrog-platform`:

   ```text
   https://jfrog-platform-artifactory:8082
   ```

<Callout icon="❗️" theme="error">
  **Important**

  The Access certificate requires the hostname IP, specified by the property `shared.node.ip` in the Artifactory `system.yaml`. This IP is automatically added to the Access certificate during startup when Access acts as the Certificate Authority (CA). While you can use a custom certificate as described in the Access TLS documentation, this is impractical in Kubernetes due to the dynamic nature of pod IPs. Instead, we recommend using a custom certificate with Nginx for TLS termination.
</Callout>

## Enable TLS for other Products in JFrog Platform

All JFrog products use Router, so enabling TLS follows the same pattern. The steps below use Xray as an example.

1. Add the following configuration in Xray’s `values.yaml` to allow Router to bypass initial TLS verification and pull the certificate.

   ```yaml
   router:
     serviceRegistry:
       insecure: true
   ```
2. After configuration, a certificate is generated under `/opt/jfrog/xray/var/data/router/keys`, and Router accepts only HTTPS requests.
3. Set `router.tlsEnabled=true` so that Kubernetes probes communicate with Router over HTTPS.

   ```yaml
   router:
     serviceRegistry:
       insecure: true
     tlsEnabled: true
   ```
4. Set `jfrogUrl` to the Artifactory service name using HTTPS. The following example uses the service name `jfrog-platform-artifactory`.

   ```yaml
   xray:
     jfrogUrl: https://jfrog-platform-artifactory:8082
   router:
     serviceRegistry:
       insecure: true
     tlsEnabled: true
   ```

   When using the JFrog Platform chart (the recommended approach for multiple JFrog products), use Helm templating to avoid hardcoding `jfrogUrl`, as shown in the [full example](#example-of-full-jfrog-platform-chart) below.

## Nginx with TLS

The following sections explain how to disable HTTP and terminate TLS with a custom certificate.

#### Disable HTTP

By default, Nginx handles both HTTP and HTTPS requests, so HTTPS works without additional configuration. To disable HTTP when Router accepts only HTTPS requests, add the following to Artifactory’s `values.yaml`:

```yaml
nginx:
  http:
    enabled: false
```

If you terminate TLS only at the load balancer and send plaintext to Artifactory, keep this option enabled — Nginx terminates SSL and passes requests to Artifactory over HTTP.

#### Terminate TLS with Custom Certificate

Starting with version 7.161, TLS certificates are no longer auto-generated at startup by default. We strongly recommend providing custom, production-grade TLS certificates to terminate TLS at the NGINX level. Your load balancer may need to trust NGINX for this connection to work correctly.

<Callout icon="❗️" theme="error">
  Auto-Generated Certificates Disabled by Default (from 7.161)

  Auto-generated certificates are not secure and are intended strictly for non-production/testing environments.

  - **Fresh Install**: Supply your own custom TLS certificates via Kubernetes secrets and configure NGINX to use them prior to deployment. If no custom certificate is provided and certificate generation remains disabled, installation will fail.
  - **Upgrades**: Existing auto-generated certificates will continue to work during upgrade. However, we strongly recommend rotating to custom, production-grade certificates.
  - **Non-Production Use**: If you explicitly require auto-generated certificates for non-production setups, you must explicitly enable the certificate generation flag `generateSelfSignedCert: true`).
</Callout>

1. Create a TLS secret using `kubectl` in the same namespace as Artifactory.

   ```bash
   kubectl create secret tls nginx-tls-secret --cert=your-cert --key=your-key -n your-namespace
   ```
2. Add it to your `values.yaml`.

   ```yaml
   nginx:
     tlsSecretName: nginx-tls-secret
   ```

   This makes Nginx use your own certificate and private key.

#### Generate Certs

To generate a self-signed certificate for Nginx TLS termination, run the following steps. Replace `artifactory.example.com` with your own domain or hostname, and `your-namespace` with the namespace where Artifactory is deployed.

1. Generate a private key.

   ```bash
   openssl genrsa -out tls.key 2048
   ```
2. Generate a certificate signing request (CSR).

   ```bash
   openssl req -new -key tls.key -out tls.csr -subj "/CN=artifactory.example.com"
   ```
3. Self-sign the CSR to produce the certificate.

   ```bash
   openssl x509 -req -in tls.csr -sha256 -days 365 -signkey tls.key -CAcreateserial -out tls.crt
   ```
4. Create the Kubernetes secret from the certificate and key, using the same secret name referenced by `nginx.tlsSecretName` in [Terminate TLS with Custom Certificate](#terminate-tls-with-custom-certificate) above.

   ```bash
   kubectl create secret tls nginx-tls-secret --cert=tls.crt --key=tls.key -n your-namespace
   ```
5. Verify the certificate and secret.

   ```bash
   openssl x509 -in tls.crt -noout -subject -dates
   kubectl get secret nginx-tls-secret -n your-namespace
   ```

## Example of Full JFrog Platform Chart

The following example configures full TLS communication for JFrog Artifactory, Xray, and Distribution using the <a href="https://github.com/jfrog/charts/tree/master/stable/jfrog-platform" target="_blank">JFrog Platform chart</a>. The `jfrogUrl` parameter is shared across all products. Helm templating ensures the URL starts with HTTPS, corresponds to the Artifactory service name, and ends with port 8082:

```yaml
global:
 jfrogUrl: '{{ printf "https://%s-artifactory:8082" .Release.Name }}'

artifactory:
  access:
   accessConfig:
     security:
       tls: true
       tls-subject-alternative-names:
         - '{{ template "artifactory.fullname" . }}'
  nginx:
    http:
      enabled: false
    tlsSecretName: nginx-tls-secret // Optional: You may skip this if you're okay with certificates generated by the Chart.

xray:
 enabled: true
 router:
   serviceRegistry:
     insecure: true
   tlsEnabled: true

distribution:
 enabled: true
 router:
   serviceRegistry:
     insecure: true
   tlsEnabled: true
```

## Add Custom Certificates to JFrog Platform

When JFrog Artifactory or other products need to access a remote private resource, such as an LDAP server, add custom certificates for the JFrog Platform to [trust](trust-a-self-signed-certificate-or-a-new-ca) those resources.

1. Create a secret that contains your certificate chain.

   ```bash
   kubectl create secret generic your-certificate-secret --from-file=your-cert.pem -n your-namespace
   ```

2. Specify the certificate secret in `values.yaml`. This works the same across all charts.

   ```yaml
   global:
     customCertificates:
       enabled: true
       certificateSecretName: your-certificate-secret
   ```

   During redeployment, the chart modifies an initContainer for each enabled product to copy certificates into the [trusted](trust-a-self-signed-certificate-or-a-new-ca) directory, allowing the application to load and trust them internally.

<Callout icon="📘" theme="info">
  **Note**

  When using `global.customCertificates` within the JFrog Platform chart, all enabled products will load the certificates.
</Callout>

## Related Topics

* [All Products - Customization](all-products-customization)
* [Set TLS on the JFrog Platform](set-tls-on-the-jfrog-platform)
* [Artifactory and Artifactory HA with Nginx SSL Termination](install-artifactory-and-artifactory-ha-with-nginx-and-terminate-ssl-in-nginx-service-load-balancer)
* [Circle of Trust Certificates](add-circle-of-trust-certificates)
* [Helm Charts for Advanced Users](helm-charts-for-advanced-users)

## Frequently Asked Questions

This section provides answers to frequently asked questions.

<Accordion title="FAQs" icon="plus">
  ##### Q: Is TLS between JFrog Platform nodes enabled by default in Helm deployments?

  **A:** No. By default, TLS between JFrog Platform nodes is disabled. You must explicitly enable it by setting `security.tls: true` under the `accessConfig` section in Artifactory's `values.yaml`.

  ##### Q: Why does the Artifactory service name need to be added as a Subject Alternative Name (SAN)?

  **A:** When all JFrog products connect to Artifactory via its Kubernetes service URL, the TLS certificate issued by JFrog Access must include that service URL in the SAN field to pass certificate validation. Without the correct SAN, TLS connections from other products to Artifactory will fail.

  ##### Q: What is the recommended approach for TLS termination in a Helm deployment?

  **A:** JFrog recommends terminating TLS at the Nginx level rather than enabling TLS within the JFrog Platform. If you terminate TLS at the load balancer and send HTTP to Artifactory, you do not need to enable internal TLS at all — Nginx handles the HTTPS offload and forwards plain HTTP requests to Artifactory.

  ##### Q: How do I add custom CA certificates so JFrog products can trust private resources like LDAP servers?

  **A:** Create a Kubernetes secret containing your certificate chain and set `global.customCertificates.enabled: true` with `global.customCertificates.certificateSecretName` pointing to that secret. When using the JFrog Platform chart, all enabled products automatically load the certificates via an initContainer. See [trust a self-signed certificate](trust-a-self-signed-certificate-or-a-new-ca) for more context.
</Accordion>

<br />