# Set up certificates

Browsers need a trusted certificate for your Blink address, or your technicians and customers see a security warning. You manage certificates in the console under **Instance** › **Certificates**. You need the instance permission **Certificates**.

:::tip[Using Blink in the cloud?]
Blink Cloud sets your instance's host names and issues and renews their certificates. The **Certificates** tab shows them, and there is nothing for you to do.
:::

## How Blink picks a certificate

For each name a browser asks for, Blink serves one certificate, in this order:

1. An **uploaded** certificate that covers the name (an exact name first, then a wildcard).
2. A **Let's Encrypt** certificate for the name.
3. The **built-in** certificate, for IP addresses and everything else.

The **Served names** card shows which certificate each name gets right now.

### Agents are never affected

Access agents and the support tool do not depend on any of these certificates. They check your server's own identity key and get its identity certificate, whatever name they connect to. Changing, uploading or deleting a certificate here never breaks agent connections. The **Agent connections** card shows the address agents connect to and the names they used recently.

## Use Let's Encrypt

Let's Encrypt issues free certificates and Blink renews them automatically.

Before you start:

- Every domain must resolve to your server in public DNS.
- Let's Encrypt must reach your server on **TCP port 443**. If the server listens on another port, forward TCP 443 to it.

1. Open **Instance** › **Certificates** and go to the **Let's Encrypt** card.
2. Tick **Use Let's Encrypt**.
3. Under **Domains**, enter one domain per line, for example `blink.example.com`. Wildcards and IP addresses are not allowed, and you can add up to 20 domains.
4. Optionally enter an **Email**. It is used only when the account is first created.
5. Under **Directory**, choose **Staging** for a first test.
6. Select **Save**. Each domain appears in the table with its **State**.
7. When the staging certificate shows **Valid**, switch the **Directory** to **Production** and select **Save** again.

:::caution[Use Staging first]
Each domain gets at most 4 attempts per hour, because Let's Encrypt allows 5 failed validations per hour. Test with **Staging** until everything works, then switch to **Production**.
:::

If a domain shows **Retrying**, the table says when the next try is and shows the last error. **Issue now** requests a certificate straight away when one is needed and the hourly limit allows it.

The states you can see are **Pending**, **Issuing**, **Valid**, **Retrying**, **Renewal overdue**, **Expiring** and **Expired**. The **Attempts** column shows how many of the 4 hourly attempts a domain has used.

## Upload your own certificate

Use this for a certificate from a commercial provider or your own private certificate authority. An uploaded certificate wins over Let's Encrypt for the names it covers.

You need:

- The **certificate chain** in PEM format: the server certificate first, then its intermediates (at most 10 certificates).
- The **private key**, unencrypted: an RSA key of 2048 bits or more, or an ECDSA P-256 or P-384 key.
- A certificate that lists the DNS names in its subject alternative names, is valid for TLS servers, and is valid now (not expired and not dated in the future). Certificates that require OCSP stapling are not supported.

1. Open **Instance** › **Certificates** and select **Upload certificate**.
2. Paste the chain under **Certificate chain**, or use **Choose file**.
3. Paste the key under **Private key**, or use **Choose file**.
4. Select **Upload**. If Blink has notes about the certificate, it shows them and the button becomes **Upload anyway**.

The certificate is served only for the DNS names it lists. IP addresses keep the built-in certificate.

:::note
The private key is stored in the server's database, so database backups include it. It is never shown again.
:::

A certificate from a private CA is marked **Private CA**: public browsers do not trust it unless your computers trust that CA. Uploaded certificates show the states **Active**, **Expiring**, **Expired**, **Not yet valid**, **Not used** (another certificate is served instead) and **Invalid**. Expiry dates are highlighted as a warning under 30 days and as urgent under 7.

To remove an uploaded certificate, select the delete icon in its row. You can keep up to 50 uploaded certificates.

## The built-in certificate

Every server creates its own certificate at first start. It is served to IP addresses and to every name no other certificate covers, and it never changes. Browsers do not trust it, so expect a warning when you use it.

The **Built-in certificate** card shows its names and its SHA-256 fingerprint, so you can check you are talking to your own server before you accept the warning.

:::tip[Locked out after a certificate change?]
The **Built-in certificate** card lists addresses that always use the built-in certificate. Note them down: if a certificate change ever locks you out of the console, open one of them and fix the certificate from there.
:::