Why services exist
Without services, a certificate is just a domain name and an expiry date. With services you can answer:- Which team is responsible when this cert expires?
- Does the payments API have valid certificates covering all its endpoints?
- Who gets notified when auth service certs are expiring?
Creating a service
Go to Services → Add Service, or create one inline during the certificate wizard (step 1: select a service → “Create new service”).Hostnames and cert groups
After creating a service, add hostnames on the service detail page. Hostnames are organized into cert groups — each group produces one certificate covering all hostnames in that group. Example: A service with three hostnames in two cert groups:
This issues two certificates: one SAN cert for both
api.* names, one for api-mgmt.
Use multiple cert groups when:
- Some hostnames need a separate cert (different CA, different validity, or separate ACME account)
- Kubernetes workloads in different namespaces need individual certs
Service coverage
The Service Coverage report (Reports → Service Coverage) shows each service with:
The dashboard Active Certs KPI counts distinct cert groups, not raw cert records.
Cert expiry reports
Reports → Service Cert Expiry lists all service-associated certs expiring within a configurable window, grouped by service with owner emails. This is distinct from the general cert expiry report which covers all certs regardless of service association. Both the Service Coverage and Service Cert Expiry reports are available as scheduled email subscriptions — go to Profile → Report Subscriptions.Owner notifications
When acert_expiring alert rule fires, CertForge sends each service’s owners a targeted email listing only the certs belonging to their service. Owners must opt in via Profile → Alert Subscriptions → Service cert expiry (notify me as service owner).
See Alerts for full alert configuration.