> ## Documentation Index
> Fetch the complete documentation index at: https://docs.certgovernance.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Applications

> Group hostnames and certificate configurations under named applications with owners.

An Application is a named business entity in CertForge that groups related hostnames into certificate configurations and assigns ownership to specific people. Applications tie certificates to the services or teams responsible for them — giving you coverage visibility, targeted alert routing, and a clear answer to "who owns this cert?" when something goes wrong.

## What is an Application?

Without applications, a certificate inventory is a flat list of hostnames and expiry dates. With applications, every certificate belongs to a context: the service it protects, the environment it runs in, and the people accountable for it.

Applications address two recurring problems:

* **Coverage gaps** — knowing that `api.example.com` has a certificate is different from knowing that the Payments API has full certificate coverage across all its hostnames. Applications make that distinction explicit.
* **Alert routing** — sending every expiry alert to a shared operations inbox creates noise. Applications let CertForge send each team only the alerts relevant to their own certificates.

## Creating an application

Applications can be created in two places:

* **Applications → New Application** — the dedicated management page for creating and editing applications independently of any certificate workflow.
* **Certificate wizard (inline)** — when creating a new certificate, you can create or select an application in the same flow without leaving the wizard.

## Application fields

| Field                       | Description                                                                           |
| --------------------------- | ------------------------------------------------------------------------------------- |
| **Name**                    | Human-readable name (e.g. "Payments API", "Customer Portal")                          |
| **Type**                    | Category: `web`, `api`, `internal`, `microservice`, `infrastructure`, or `other`      |
| **Environment**             | Deployment environment: `production`, `staging`, `development`, `testing`, or `other` |
| **Hostnames / cert groups** | One or more cert groups, each containing a set of hostnames                           |
| **Owners**                  | One or more email addresses identifying the people responsible for this application   |

## Cert groups

A single application often needs more than one certificate — for example, when a wildcard doesn't cover all required SANs, or when different hostnames must use different CAs or key types.

Each cert group within an application contains a set of hostnames that will be covered by a single certificate. CertForge tracks coverage at the cert group level: a group is covered when a valid, managed certificate exists for those hostnames, and uncovered when it does not.

One application can have multiple cert groups. This supports multi-cert configurations without needing to split conceptually related hostnames across separate applications.

## Coverage status

The Applications page shows a coverage status for each application, computed across all its cert groups.

| Status       | Meaning                                                     |
| ------------ | ----------------------------------------------------------- |
| **Full**     | Every cert group has a valid, managed certificate           |
| **Partial**  | At least one cert group is covered, but one or more are not |
| **None**     | No cert group has coverage, but cert groups are defined     |
| **No certs** | No cert groups configured yet                               |

## Application owner notifications

When a `cert_expiring` alert rule fires, CertForge sends a targeted email to each application's owners listing only the certificates belonging to that application. This is separate from the org-wide alert channel — owners receive a focused view of what they are responsible for, not a list of every expiring cert in the organization.

This notification is opt-in. Go to **Profile → Alert Subscriptions** and check **Service cert expiry (notify me as service owner)**. Owners who do not opt in will not receive the targeted email, but org-wide alert channels will still fire as configured.

<Note>
  Application owner notifications require an email address on your account and SMTP configured by your admin. See [Email Setup](/guides/email-setup) for configuration details.
</Note>

## Reports

Two reports are available specifically for applications. Both are accessible at the **Reports** page and can be subscribed to as scheduled email deliveries from **Profile → Report Subscriptions**.

### Application Coverage

Lists every application in the organization with:

* Hostname count
* Cert group count
* Owner emails
* Coverage status (Full / Partial / None / No certs)

Use this report to identify applications with gaps before those gaps cause outages.

### Application Cert Expiry

Shows application-associated certificates expiring within a configurable number of days, with the application name and owner emails alongside each certificate. This report makes it straightforward to hand off expiry work to the right team — or confirm that automated renewal is tracking correctly.

### Enriched standard reports

The **Certificate Inventory** and **Expiring Certificates** reports include **Application** and **Owners** columns when applications are configured, providing application context across all certificate reporting.

For more on reports and scheduled delivery, see [Reports](/concepts/reports).