Using EverTLS

Everything you need to go from your first domain to a fleet of servers that renew themselves. Examples use example.com and placeholder tokens; replace them with your own.

Getting started

Create an account

Sign up at app.evertls.com and confirm your email address. Signing up creates an organization that you own; everything else (certificates, domains, agents, alert channels, API tokens) belongs to an organization. You can create more organizations and switch between them from the dashboard.

Your team and roles

Invite colleagues under Settings → Team. Each member has one role in an organization:

Company domains (Settings → Team): prove that you own your email domain and colleagues who sign up with it ask to join your organization instead of creating their own. An admin approves each request.

Two-factor sign-in and single sign-on

• Two-factor sign-in: turn it on under Settings → Account with any authenticator app. Admins can require it for every member under Settings → Security; members without it are asked to set it up before they can continue.
• Single sign-on: owners can connect an OpenID Connect identity provider (Microsoft Entra ID, Google Workspace, Okta and others) under Settings → Security for the organization’s verified company domains, and require it for every member below owner. People who sign in through SSO satisfy a two-factor requirement through your identity provider.

Issuing certificates

Go to Certificates → New certificate.

1. Domains. One name per line. A certificate can cover several names; wildcards such as *.example.com need a DNS validation method.
2. Private key. Choose where the key is created (see Private keys). Key types: ECDSA P-256 (default), P-384, or RSA 2048, 3072 or 4096.
3. Validation. Choose how the CA checks you control the domains (see Domain validation).
4. Install (optional). Pick an agent and a target so every renewal is installed automatically.

Many at once. The Many at once tab takes one certificate per line, with a certificate’s names separated by spaces. EverTLS can detect each domain’s DNS provider, and you can have every certificate installed by an agent, for example into the Windows certificate store or exported as PFX files, each with its own password.

Certificates come from Let’s Encrypt on EverTLS Cloud. Self-hosted installations can also use a private ACME CA such as step-ca.

Domain validation

You set up validation once per domain; renewals reuse it. Manage it under Validation → Domains, where Check tests the setup.

If the site forces HTTPS, keep that redirect for the HTTP method; the CA follows it. Exclude the challenge path from login pages and WAF rules.

Private keys and renewals

• On the agent’s server. The agent generates a fresh private key on your server for every renewal and sends EverTLS only a certificate signing request. The key never leaves that server. Renewals need the agent online.
• Your own CSR. Paste a PEM CSR; you hold the key. Renewals reuse that CSR. To rotate the key, request a new certificate with a new CSR.
• Generated by EverTLS. The simplest option, and needed if you want to download the key or a PFX from the dashboard. The key is encrypted at rest, and every key download is recorded in the audit log.

Renewals are automatic. EverTLS asks the CA when to renew (ACME Renewal Information); if the CA doesn’t say, it renews at two thirds of the certificate’s lifetime. Failed attempts are retried, and you’re alerted if they keep failing. When an agent installs the renewal, it tests the configuration, reloads, checks the new certificate is served and rolls back if anything fails.

Downloads and exports

On a certificate’s page, under Download:

• PEM: full chain, certificate, or chain; DER (.cer).
• Private key (PEM) and PFX (AES-256, for IIS and Windows), when EverTLS generated the key. Enter the PFX password you want.
• Legacy PFX (3DES) for Windows Server 2016 and older Java.

Downloads that contain the private key need the member role or above. To automate downloads, use the REST API or an agent files target.

Agents

The evertls-agent runs on your server, finds the TLS sites on it, and installs certificates. It only makes outbound HTTPS connections to EverTLS and opens no ports. Agent releases are signed, and the installers refuse anything that isn’t (see Security).

Enrollment tokens

Admins open Agents → Add agent and choose:

• One server: a single-use token, valid for 24 hours.
• Many servers: a reusable token for automation (Ansible, server images), valid for 7 days. Treat it like a password.

The dashboard then shows the install command with the token filled in. The agent appears in the list a few seconds after installing.

Linux

Ubuntu, Debian, RHEL, Rocky, Alma, Amazon Linux and other distributions with systemd. Run on the server:

curl -fsSL https://evertls.com/agent/install.sh | sudo sh -s -- --token evta_YOUR_ENROLLMENT_TOKEN

• --name NAME: the name shown in the dashboard (default: the hostname).
• --restricted: run as the unprivileged user evertls-agent instead of root. It may write only to /etc/evertls and run the reload commands listed in /etc/sudoers.d/evertls-agent, and it runs sandboxed.
• --uninstall: stop and remove the agent, its identity and its keys. Certificates it installed stay in place; revoke the agent in the dashboard too.

Windows

Windows Server 2016 or later, and Windows 10/11. Run in PowerShell as Administrator; it installs the evertls-agent service:

[Net.ServicePointManager]::SecurityProtocol = 'Tls12'; & ([scriptblock]::Create((irm https://evertls.com/agent/install.ps1))) -Token evta_YOUR_ENROLLMENT_TOKEN

Options: -Name, -AllowFolder D:\Certs (extra export folders) and -Uninstall. On Windows the agent’s local secrets are encrypted with DPAPI and readable only by SYSTEM and Administrators.

Useful agent commands

On Linux run them with sudo evertls-agent …; on Windows, in PowerShell as Administrator, with & "C:\Program Files\EverTLS\evertls-agent.exe" ….

evertls-agent status      # the enrolled identity
evertls-agent discover    # the sites found on this host
evertls-agent version

Install targets

On a certificate’s page, add a deployment: pick an agent and a target. Every renewal is then installed there automatically.

Files and PFX options

• The folder can contain {name}, replaced by the certificate’s name (*.example.com becomes _wildcard.example.com).
• PFX only, without the PEM files; an extra legacy (3DES) copy for Windows Server 2016 and older Java.
• PFX password: one the agent generates (saved as password.txt next to the PFX, or kept in the agent’s encrypted store), or one you set on the server (see PFX passwords). EverTLS never sees these passwords.

Allowing export folders

The agent writes only to its own folders (/etc/evertls on Linux, C:\ProgramData\EverTLS on Windows) and to folders you allow on that server. EverTLS can’t add folders remotely. To allow one:

sudo evertls-agent folders allow /srv/certs
& "C:\Program Files\EverTLS\evertls-agent.exe" folders allow "D:\Certs"

The folder is created and limited to the agent and administrators. folders list shows what’s allowed; the running agent picks up changes within a minute.

Upgrading agents

Run the installer again without a token. It upgrades the agent and keeps its identity:

# Linux
curl -fsSL https://evertls.com/agent/install.sh | sudo sh

# Linux, restricted agents (keep them restricted)
curl -fsSL https://evertls.com/agent/install.sh | sudo sh -s -- --restricted

# Windows (PowerShell as Administrator)
[Net.ServicePointManager]::SecurityProtocol = 'Tls12'; & ([scriptblock]::Create((irm https://evertls.com/agent/install.ps1)))

When a newer release exists, the agent shows Update available in the dashboard, with the right command for that server.

Options need a minimum agent version. An old agent would silently ignore options it doesn’t understand, so EverTLS refuses to save a deployment the target agent can’t carry out and tells you how to upgrade it. These options need agent 0.14.0 or newer: PFX files, PFX without PEM files, PFX passwords stored on the agent (including {name}), generated PFX passwords and keeping them in the agent’s store, the legacy PFX copy, {name} in the folder path, and exportable keys in the Windows certificate store.

API keys kept locally

You can keep secrets on your own servers so EverTLS never receives them. The agent stores them in its state folder, readable only by the agent (and on Windows also encrypted with DPAPI for that machine, so a copied file is useless elsewhere). EverTLS only learns their names.

DNS provider keys on the agent

Use this for DNS validation (and wildcards) without giving EverTLS your DNS API key.

# find your provider's code
sudo evertls-agent dns providers cloudflare

# add a key; you're asked for each setting (secrets aren't echoed)
sudo evertls-agent dns add example-dns --provider cloudflare

# or read NAME=value lines from a file instead of typing them
sudo evertls-agent dns add example-dns --provider cloudflare --env-file /root/dns.env

# check it can create and remove a record in your zone
sudo evertls-agent dns test example-dns example.com

sudo evertls-agent dns list               # names and providers only
sudo evertls-agent dns remove example-dns

Then, in the dashboard, set the domain’s validation to DNS · key on agent and pick the agent and the key’s name. When a certificate is issued or renewed, EverTLS asks the agent to create the _acme-challenge records, and the agent does it with the local key. If you use --env-file, delete the file afterwards.

PFX passwords on the agent

sudo evertls-agent pfx-password set shop.example.com     # asks for it twice
sudo evertls-agent pfx-password list
sudo evertls-agent pfx-password show shop.example.com    # e.g. one the agent generated
sudo evertls-agent pfx-password remove shop.example.com

In a files target, choose a password stored on the server and give its name. Use {name} as the name and each certificate uses the password named after it (for example shop.example.com), so every PFX has its own password. Generated passwords kept in the agent’s store are named after the certificate too; read them with pfx-password show.

API tokens and the REST API

Use an API token to automate EverTLS from scripts, CI pipelines or your own machine. Admins create them under Settings → API tokens:

• Give it a name and a role (viewer, member, admin or owner, no higher than your own). The token can do what that role can do, in that organization only.
• It starts with evt_ and is shown once. Copy it into a secret store or environment variable, never into code or a repository.
• Networks limits a token to IP addresses or ranges, within the organization’s own network restrictions. Revoke stops it at once. Each token shows when it was last used.

Using a token locally

Send it as a Bearer token to https://app.evertls.com/api/v1. Keep it in an environment variable rather than typing it into commands:

export EVERTLS_URL=https://app.evertls.com
export EVERTLS_TOKEN=evt_YOUR_API_TOKEN

# list certificates
curl -fsS -H "Authorization: Bearer $EVERTLS_TOKEN" "$EVERTLS_URL/api/v1/certificates"

# request a certificate validated by CNAME delegation
curl -fsS -X POST -H "Authorization: Bearer $EVERTLS_TOKEN" -H "Content-Type: application/json" \
  -d '{"domains":["shop.example.com","*.shop.example.com"],"validation_method":"dns01_cname"}' \
  "$EVERTLS_URL/api/v1/certificates"

# download the full chain (public formats can use GET)
curl -fsS -H "Authorization: Bearer $EVERTLS_TOKEN" -o fullchain.pem \
  "$EVERTLS_URL/api/v1/certificates/CERT_ID/download?format=fullchain"

# check whether the current certificate is live on its endpoints
curl -fsS -X POST -H "Authorization: Bearer $EVERTLS_TOKEN" "$EVERTLS_URL/api/v1/certificates/CERT_ID/verify-install"

Formats: fullchain, cert, chain, der, and, with the key, key, pfx and pfx-legacy. Formats that contain the private key must be requested with POST, so passwords never travel in URLs, and need a member token or above:

curl -fsS -X POST -H "Authorization: Bearer $EVERTLS_TOKEN" -H "Content-Type: application/json" \
  -d "{\"format\":\"pfx\",\"password\":\"$PFX_PASSWORD\"}" -o certificate.pfx \
  "$EVERTLS_URL/api/v1/certificates/CERT_ID/download"

In PowerShell:

$env:EVERTLS_TOKEN = "evt_YOUR_API_TOKEN"
$headers = @{ Authorization = "Bearer $env:EVERTLS_TOKEN" }
Invoke-RestMethod -Headers $headers https://app.evertls.com/api/v1/certificates

Other useful endpoints: GET /domains, GET /agents, GET /monitors, GET /audit, and POST /certificates/batch for many certificates at once. Errors come back as JSON with an error message. The evertls command-line client reads the same EVERTLS_URL and EVERTLS_TOKEN variables.

Monitoring and alerts

• Monitoring: add any HTTPS endpoint (host, host:port or a URL), including certificates EverTLS doesn’t manage. Endpoints are checked every few hours for expiry, trust and hostname problems. Certificates you issue are also checked on their endpoints after each renewal, so you know the new one is actually serving.
• Alerts: add channels under Alerts: email, Slack, Microsoft Teams or a webhook (signed with a secret shown once). Each channel can subscribe to: issued or renewed, issuance failed, installed, install overdue, expiring, deployment failed, and agent offline, plus monitoring problems. Use Test to send a test message.

Audit log and network access

• Audit log (Settings → Audit log): a tamper-evident record of security-relevant actions, such as key downloads, token and member changes, and setting changes.
• Network restrictions (Settings → Security, admins): allow the dashboard, the API and agents only from listed IP addresses and ranges. API tokens can be narrowed further with their own list.

FAQ

Still stuck? Email hello@evertls.com. Security issues: security@evertls.com.