Skip to main content

First Certificate

Goal: prove your Certeasy instance works end-to-end by issuing one certificate. We use certbot with HTTP-01 because it's the safest "out of the box" combination — certbot's defaults (RSA 4096 key, serverAuth only EKU) line up with Certeasy's default policy without any tuning.

If you already know which client you want to use, skip straight to its fiche:

ClientBest fitFiche
certbotLinux servers, distro packages, widest docsACME Clients → certbot
legoContainers / CI, static binary, ECDSA defaultACME Clients → lego
acme.shMinimal systems, pure shell+curl, no Python/GoACME Clients → acme.sh

Each fiche covers HTTP-01 (standalone + webroot), DNS-01, renewal and revocation for that specific client, plus the gotchas (key types, trust store, EKU…).

Prerequisites

  • Certeasy running and accessible at https://acme.corp.internal
  • certbot installed on the target machine
  • Port 80 reachable on the target machine from Certeasy's configured DNS resolver
  • The target machine's DNS name is allowed by your issuance policy
  • Your internal CA deployed to the OS trust store (see Trusting your internal CA on the certbot fiche)

Issue your first certificate

export REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt # adapt for RHEL
certbot certonly \
--standalone \
--preferred-challenges http \
--server https://acme.corp.internal/acme/directory \
-d app.corp.internal

What happens:

  1. certbot opens port 80 inside its process.
  2. certbot POSTs an order to Certeasy.
  3. Certeasy fetches http://app.corp.internal/.well-known/acme-challenge/<token> and verifies the response.
  4. Certeasy forwards the CSR to your back-end CA (ADCS or fakepki).
  5. certbot writes the issued certificate under /etc/letsencrypt/live/app.corp.internal/.

Check the result

openssl s_client -connect app.corp.internal:443 -showcerts

You should see a certificate issued by your internal CA.

Next steps

Troubleshooting

If this minimal scenario fails, the certbot fiche has the comprehensive coverage. Three most common causes on a fresh setup:

  • TLS handshake fails before any cert request: the internal CA isn't in the OS trust store, and REQUESTS_CA_BUNDLE isn't set. Re-read Trusting your internal CA.
  • Challenge validation fails: port 80 isn't reachable from Certeasy's host, or certbot can't bind it (run as root or grant cap_net_bind_service).
  • DNS name rejected: the target FQDN is outside the allow list of your issuance policy.