Self-signed certificates
Tines uses one certificate so browsers can open your tenant, and a separate set of trusted certificates when a story, a case webhook, or a sign-in flow connects to another server. Trusting a certificate in the browser does not make stories trust it.
Issue the browser certificate for the hostname in DOMAIN. Put that hostname in the Common Name and in a subject alternative name. A self-signed certificate is enough for a lab. For production, use a certificate from a certificate authority (CA) that browsers and the rest of your network already trust.
Where you attach that certificate depends on where TLS terminates:
Docker Compose presents
tines.crtandtines.keyfrom Nginx.AWS Fargate presents an AWS Certificate Manager certificate from the load balancer.
Helm presents a certificate from Nginx, from your ingress or cloud load balancer, or from an OpenShift route.
SSL/TLS termination covers presenting a certificate directly from
tines-app.
A public CA at the load balancer means other systems that trust public CAs can call your tenant without extra configuration. A self-signed or private certificate has to be trusted by each outbound connection below.
Which connection needs which certificate
AI providers can use a custom certificate authority when they connect to a private service. Mutual TLS, where Tines presents a client certificate, is a credential setting and does not change which CA Tines trusts.
Trust a certificate for stories
Export the PEM-encoded certificate. For a private CA, use the CA certificate that signed the server. For a self-signed server, use that server certificate. Include intermediate certificates in order after the leaf certificate when the server's chain needs them.
Open Settings > Custom Cert Authorities, or https://<tenant-domain>/settings/custom_ca.
Paste the PEM into the authority named default and save. To trust several unrelated servers from every story and from case webhooks, paste each PEM certificate into that same authority, one after another.
Create a named authority when one HTTP Request, IMAP, or gRPC action should trust a different CA. Set custom_certificate_authority_name on that action. Case webhook notifications keep using default.
The authority is stored for the tenant and is added to the public authorities already in the container. Saving it takes effect on the next run, on Docker Compose, AWS Fargate, and Kubernetes. You do not restart tines-sidekiq or mount a file for this path.
An HTTP Request action that fails with certificate verify failed and mentions disable_ssl_verification does not trust the server certificate. Add the CA, then leave disable_ssl_verification unset. Turning verification off accepts any certificate for that action.
Let stories call this Tines tenant
Case webhook notifications often post to a webhook action on the same tenant, and stories often call the Tines API at https://<DOMAIN>. Both are outbound HTTPS requests from tines-sidekiq to whatever certificate your deployment presents for that hostname.
When that certificate comes from a public CA, such as the AWS Certificate Manager certificate on an AWS Fargate load balancer, tines-sidekiq already trusts it. When it is self-signed or issued by a private CA, add the public certificate to the custom certificate authority named default.
The hostname in the action or webhook URL must match the certificate name. A certificate issued for a different name fails verification even after it is trusted. Browsers still warn about a self-signed certificate until each user trusts it, or until you replace it with a certificate those browsers already trust.
Trust a certificate for single sign-on
Single sign-on runs in tines-app and uses that container's trust store. A custom certificate authority has no effect on it.
Build a CA bundle that contains the public authorities and your private CA, and provide that file in every tines-app container at /etc/ssl/certs/ca-certificates.crt. Provide the bundle, rather than a single certificate file. That path replaces the bundle shipped in the image, so it needs the public authorities as well as your CA.
On a Linux host you can add the CA and then use the resulting bundle:
Ubuntu or Debian: copy the .crt file to /usr/local/share/ca-certificates/ and run update-ca-certificates. The bundle is /etc/ssl/certs/ca-certificates.crt.
RHEL, CentOS, or Fedora: copy the file to /etc/pki/ca-trust/source/anchors/ and run update-ca-trust extract. The bundle is /etc/pki/tls/certs/ca-bundle.crt.
Deliver that bundle with the same mechanism you use for other files on the platform: a read-only volume on Docker Compose, a secret or config map mounted onto the tines-app pods on Kubernetes, or a file in the AWS Fargate task. Restart tines-app after the file changes. The file stays in place when you upgrade the Tines image.
Story actions and case webhooks still use Custom Cert Authorities, so tines-sidekiq does not need this file for those connections.
TLS inspection proxies
A proxy that re-signs HTTPS presents its own CA. Trust that CA in the same place as the connection it intercepts:
Stories and case webhooks: add the proxy CA as a custom certificate authority.
Single sign-on: add the proxy CA to the tines-app bundle.
Set HTTP_PROXY and HTTPS_PROXY on the containers that should use the proxy. Set NO_PROXY for the database, Redis, and other internal hosts that should connect directly. Those variables are in the environment variable reference.