Introduction
Farrier is an open-source, agentless machine identity automation platform. It discovers, manages and secures the machine identities across your infrastructure: TLS certificates, SSH keys, cryptographic assets and post-quantum (PQC) readiness. Your team oversees; Farrier handles the rest.
Nothing is installed on the machines it manages. Farrier works over the network: TLS handshakes, SSH, and each device's management API.
What it manages
- TLS certificates. It finds what your endpoints actually serve, plans renewals into change windows, issues certificates on the device's behalf, deploys them (or hands a person a change pack), and only calls a renewal done when a handshake shows the new certificate live. This includes the machines ACME can't reach: load balancers, firewalls, VPN concentrators, Java keystores and vendor appliances.
- SSH keys. Host keys and algorithms from a scan, and
authorized_keysfrom each host. Weak and unknown keys are flagged and can be removed. See SSH keys. - Cryptography and PQC readiness. Protocol versions, ciphers and key exchange for every TLS and SSH service, a post-quantum status for each, and a CycloneDX CBOM. See Crypto and PQC readiness.
- Tickets and events. ServiceNow and Jira tickets that follow each manual change, and events to Datadog and Splunk. See Integrations.
The problem
The CA/Browser Forum's ballot SC-081 shortens the maximum lifetime of public TLS certificates in steps:
| From | Max lifetime | Domain-validation reuse |
|---|---|---|
| 1 Sep 2020 | 398 days | 398 days |
| 15 Mar 2026 | 200 days | 200 days |
| 15 Mar 2027 | 100 days | 100 days |
| 15 Mar 2029 | 47 days | 10 days |
Cloud workloads already auto-renew with certbot, cert-manager or their platform. The pain is the long tail: anything that needs an API call to a management plane, a keystore rewrite and restart, or a ticket and a human in a maintenance window. At 47 days, an estate of 1,000 certificates with 40% installed by hand needs about 47 renewals every working day and more than two full-time engineers. Run farrier forecast to see your own numbers.
How Farrier closes the gap
The device never talks to a CA. Farrier completes ACME DNS-01 validation through your DNS (or uses its built-in private CA), then:
- Automated connectors push the certificate to F5 BIG-IP, FortiGate, PAN-OS, Java keystores and any host with files over SSH. Each install goes in under a new name, switches over, and records how to undo it.
- The manual connector builds a change pack (PEM, PFX, a device-specific runbook) and can open a ServiceNow or Jira ticket. The renewal closes itself when the scanner sees the new certificate live.
- Verification is a real handshake. If an automated deploy never shows the new fingerprint, Farrier rolls back.
Who it's for
Infrastructure, network, PKI and security teams who own a mixed estate of appliances, servers and legacy services, and who need machine identities handled in a way that respects change control instead of bypassing it.
Project status
The engine is covered by tests, including an in-process RFC 8555 ACME server and mock appliance APIs. The F5, FortiGate and PAN-OS connectors follow the vendors' documented APIs but have not yet been run against real hardware. Try them on a lab device, and use Let's Encrypt staging, before production.
How these docs are organised
- Quickstart: run the demo estate and the dashboard in five minutes.
- Concepts: the lifecycle, the renewal state machine, timing maths and change windows.
- Configuration: data directory, issuers, DNS hooks, settings, inventory, environment variables and CLI.
- Connectors: configuration for each connector, and how to write your own.
- SSH keys, Crypto and PQC readiness and Integrations: the identities beyond TLS, and where tickets and events go.
- API reference: every REST endpoint.
- Self-hosting: running Farrier and the dashboard in production, including Docker.
- Security: how keys and secrets are handled, and how to report a vulnerability.
- Design system and Contributing: for people working on Farrier itself.