# EST Use EST for network infrastructure such as VPN gateways, routers, switches, appliances, and IoT fleets. Each endpoint has its own base URL: ```text https://pki.example.com/.well-known/est/ ``` The base provides `/cacerts`, `/simpleenroll`, `/simplereenroll`, and `/csrattrs`. Most clients require only the base URL. HTTPS is required. On the **EST** tab of SCEP · ACME · EST, select **Add endpoint**, enter a name, and select an issuing CA. ![An EST endpoint page, with base URL and enrollment credentials](/assets/docs/est-endpoint-page.png) ## Clients authenticate with a password, not a certificate Configure your client for HTTP Basic. A client set up to present a TLS client certificate will be refused. SimpleSCEP terminates TLS before the application, so it uses **HTTP Basic over server-authenticated TLS** as permitted by RFC 7030 §3.2.3. The username and password are sent with every enrollment and re-enrollment. Plaintext requests return `403` without an authentication challenge. Revoke any credential sent over plaintext. `/simplereenroll` is authenticated by two things together: 1. the same Basic credential, and 2. a **binding check** — the subject in the CSR must already hold a live certificate this endpoint issued, and the request must fall inside the renewal window. An expired EST credential blocks both enrollment and renewal. Leave the expiry blank for long-lived fleets. ## Enrollment credentials Under **Enrollment credentials**, select **Mint credential**. Use one per fleet or device. The password is shown once; mint another if it is lost. ![The Mint an enrollment credential dialog](/assets/docs/est-credential.png) | Field | What it does | | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Username | The Basic username. No spaces or colons, up to 64 characters, and unique per endpoint, case-insensitively | | Label | For your records only | | Pin to these names (optional) | Comma-separated exact names. A client using this credential can enroll only these, checked against the CSR's common name, DNS names, and IP addresses. The match is exact, not a prefix or substring — a CSR common name of `gw-muc-01` will not match a pin of `gw-muc-01.example.internal`. Blank falls back to the endpoint's patterns | | Expires after (hours) | Bounds how long the credential works, for enrollment **and** renewal. Blank never expires | **Revoking a credential stops the next enrollment and the next renewal.** Certificates already issued keep working until they expire. For provisioning scripts, the route also accepts JSON: ```bash curl -sS -X POST \ https://pki.example.com/api/est/endpoints//credentials \ -H 'Content-Type: application/json' \ -d '{"username":"branch-gateways","label":"EMEA branches","identifiers":"gw-muc-01.example.internal","ttl_hours":720}' # → {"url":"…/.well-known/est/","username":"branch-gateways","password":"…"} ``` ## Configure a client Every client needs to trust every certificate above the one `/simpleenroll` hands back — and that's more than one file for most organizations. Two separate things feed into it: 1. **Your own CA's chain**, fetched once from `/cacerts` (no credentials needed — see below). This is **one certificate for a single-tier CA, or two for a root-plus-issuing-CA setup**, which is the common case. `/simpleenroll` and `/simplereenroll` return only the newly issued leaf, never the chain above it, so a client needs this fetched and trusted ahead of time — the same way it needs the credential ahead of time. 2. **The public or private root behind your deployment's TLS certificate**, which verifies the connection to the endpoint itself and is independent of your SimpleSCEP CA. A browser or a machine with a full OS certificate bundle already trusts #2 and needs nothing extra for it. Many EST clients — strongSwan's `pki` tool included — trust only what you hand them explicitly and don't fall back to a system store, so both are needed regardless of how many certificates are in each. Fetch your chain once, from a trusted channel, and keep each certificate in its own file — most clients that take an explicit trust list read only one certificate per file or per argument, so a bundle with more than one certificate concatenated together silently loses everything after the first: ```bash curl -s https://pki.example.com/.well-known/est//cacerts \ | base64 -d | openssl pkcs7 -inform DER -print_certs -out chain.pem awk '/BEGIN CERTIFICATE/{n++} {print > ("simplescep-ca" n ".pem")}' chain.pem # simplescep-ca1.pem is the certificate nearest your device's; simplescep-ca2.pem # (if your CA is root-plus-issuing) is the root above it. ``` Get the TLS root from your deployment operator through a trusted channel rather than fetching it from the endpoint itself. Use a self-signed trust anchor; a client that only trusts self-signed roots may reject a cross-signed copy of the same key. **strongSwan** ```bash pki --est --url https://pki.example.com --label \ --userpass 'branch-gateways:' \ --in gw-muc-01.req \ --cacert simplescep-root.pem \ --cacert simplescep-issuer.pem \ --cacert deployment-tls-root.pem \ --outform pem > gw-muc-01.pem ``` `--url` is the base URL only. strongSwan builds `/.well-known/est/