FreeIPA Dogtag Certs

Issue, track and renew service certificates with FreeIPA's bundled Dogtag CA: sub-CAs, ipa cert-request, certmonger, ACME, renewing the IPA CA itself, and the errors that show up in practice.

The Dogtag model in IPA

When you install IPA with --setup-ca, you get:

• Dogtag PKI (pki-tomcatd@pki-tomcat) running on loopback.
• An IPA CA with subject CN=Certificate Authority,O=EXAMPLE.INTERNAL by default.
• A certmonger tracking entry for the CA's own cert, so Dogtag's signing cert auto-renews.
• A small number of profiles you can issue against (caIPAserviceCert by default, plus IECUserRoles et al.).

Sub-CAs (ipa ca-add)

Create a sub-CA when you want a trust domain narrower than "everything our IPA ever signs". For example: a sub-CA for internal mTLS that you can distribute to Kubernetes without also trusting every cert IPA issues.

kinit admin

# Create the sub-CA
ipa ca-add internal-mtls \
  --subject "CN=Internal mTLS,O=EXAMPLE.INTERNAL" \
  --desc "mTLS between internal services"

# See what exists
ipa ca-find

# Fetch the sub-CA cert to ship to consumers
ipa ca-show internal-mtls --out /etc/pki/ca-trust/source/anchors/internal-mtls.pem
update-ca-trust

Issuance is now parameterised by --ca=:

ipa cert-request /tmp/app.csr \
  --principal HTTP/app1.example.internal \
  --ca internal-mtls \
  --profile caIPAserviceCert

Issuing service certs

Three steps: create the service principal, generate a CSR, request the cert.

1. Generate a CSR

# On the host that needs the cert
sudo -u app openssl req -new -newkey rsa:4096 -nodes \
  -keyout /etc/pki/tls/private/app.key \
  -out /tmp/app.csr \
  -subj "/CN=app1.example.internal" \
  -addext "subjectAltName=DNS:app1.example.internal,DNS:app.example.internal"

For modern workloads, prefer ECDSA P-256 or Ed25519 where supported:

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
  -keyout /etc/pki/tls/private/app.key -out /tmp/app.csr \
  -subj "/CN=app1.example.internal" \
  -addext "subjectAltName=DNS:app1.example.internal"

2. Ensure the service principal exists

ipa service-add HTTP/app1.example.internal
# If this host is not the app's own, authorise the requester explicitly:
ipa service-add-host HTTP/app1.example.internal --hosts=deploy01.example.internal

3. Request the cert

ipa cert-request /tmp/app.csr \
  --principal HTTP/app1.example.internal \
  --profile caIPAserviceCert \
  --ca ipa \
  --certificate-out /etc/pki/tls/certs/app.pem

The returned cert chains to the IPA CA (or whatever sub-CA you asked for). Combine with the CA bundle if the consumer needs it:

ipa ca-show ipa --out /etc/pki/tls/certs/ipa-ca.pem
cat /etc/pki/tls/certs/app.pem /etc/pki/tls/certs/ipa-ca.pem \
  > /etc/pki/tls/certs/app-fullchain.pem

Tracking with certmonger

Manual issuance is fine for a one-off. For anything that lives past a renewal cycle, track with certmonger so it renews itself.

sudo ipa-getcert request \
  -K HTTP/app1.example.internal \
  -D app1.example.internal -D app.example.internal \
  -k /etc/pki/tls/private/app.key \
  -f /etc/pki/tls/certs/app.pem \
  -C "systemctl reload nginx" \
  -r

Inspect and manage

sudo getcert list
sudo getcert list -i <request-id>            # details for one request
sudo getcert resubmit -i <request-id>        # force a renewal
sudo getcert stop-tracking -i <request-id>   # stop certmonger from touching it

ACME on IPA

IPA has shipped an ACME endpoint for a while. If your consumer speaks ACME, this is the lowest-friction option — no keytabs, no service principals, just HTTP-01.

sudo ipa-acme-manage enable
sudo ipa-acme-manage status
# Directory URL to hand to your ACME client:
#   https://ipa1.example.internal/acme/directory

Client side, with certbot:

certbot certonly --standalone \
  --server https://ipa1.example.internal/acme/directory \
  -d app1.example.internal \
  --no-eff-email --agree-tos -m devops@example.internal

And with acme.sh:

acme.sh --issue -d app1.example.internal \
  --server https://ipa1.example.internal/acme/directory \
  --standalone

Restrictions:

• The requester must be able to prove control of the name. HTTP-01 needs port 80 reachable by the IPA server.
• Only DNS names already known to IPA (A/AAAA or a matching host entry) are signed by default.
• No EAB; authentication is "you solved the challenge".

Renewing the IPA CA

The CA signing cert has a lifetime. By default it is ~10 years, but early installs used shorter lifetimes; some regulated environments force shorter. You will renew eventually.

Check when

sudo ipa-certupdate                           # fetch current trust bundle
sudo getcert list | grep -E 'subject|expires' | head -40

# Or directly from Dogtag:
sudo openssl x509 -noout -dates \
  -in /etc/pki/pki-tomcat/alias/ca_signing.crt

Renew (internal-CA mode)

# Certmonger already tracks the CA cert. Force it:
sudo ipa-cacert-manage renew --self-sign
sudo ipa-certupdate     # push the new trust bundle to all clients via SSSD

Renew (external-CA mode)

# Step 1: generate a CSR for the IPA CA
sudo ipa-cacert-manage renew --external-ca

# This writes /var/lib/ipa/ca.csr. Hand it to your corporate root.
# Step 2: receive the signed cert + chain back, then:
sudo ipa-cacert-manage renew \
  --external-cert-file=/tmp/ipa-ca.new.crt \
  --external-cert-file=/tmp/corp-root.pem
sudo ipa-certupdate

External-CA mode

Decision at first ipa-server-install:

ipa-server-install --external-ca \
  --realm EXAMPLE.INTERNAL --domain example.internal \
  --setup-dns --auto-forwarders \
  --ds-password 'REDACTED' --admin-password 'REDACTED' \
  --unattended

# Installer pauses and emits /root/ipa.csr. Sign it with the corporate CA.
# Resume with the signed cert and the corporate chain:
ipa-server-install --external-cert-file=/root/ipa.crt \
                   --external-cert-file=/root/corp-root.pem

Trade-offs:

• Pro: Every cert IPA issues chains to your corporate root. Downstream consumers already trust it.
• Pro: Revocation story is unified with the rest of your PKI.
• Con: Renewal involves two teams on a schedule.
• Con: If the corporate CA team's OID/profile doesn't allow the name constraints IPA needs, you find out late.

Profiles, short version

A profile is a Dogtag template for "what fields are allowed/required on this kind of cert". IPA ships a few:

Custom profiles are possible (ipa certprofile-import) when you need ExtKeyUsage combinations the default won't emit (e.g. TLS client + code signing). Treat them like CA change-management: version-controlled, reviewed, tested on a non-prod sub-CA first.

Common errors

Verification

• [ ] ipa-healthcheck --failures-only is clean on every CA replica
• [ ] getcert list lists every cert certmonger tracks, all in status MONITORING
• [ ] CA renewal date is > 12 months away, or a renewal event is scheduled
• [ ] At least two IPA servers have --setup-ca
• [ ] Sub-CA public certs are in /etc/pki/ca-trust/source/anchors/ on every consumer that needs them
• [ ] ACME directory URL is in the standard internal runbook if you enabled it
• [ ] ipa cert-show 1 returns the CA cert — if it errors you have a bigger problem

See also: FreeIPA, FreeIPA Replication, Certificates, Kerberos Keytab Rotation.