# pfSense Certificates - CA, TLS, Let's Encrypt

> Creating and managing certificates in pfSense - internal CA, server and client certificates, ACME package for Let's Encrypt automation

Source: https://opennix.org/en/docs/pfsense/certificates/pfsense-certificate-management/


The pfSense Certificate Manager (System > Certificates) provides centralized management of all PKI components - Certificate Authorities, certificates, and revocation lists. All certificates used by pfSense services are stored in a unified repository and available for selection in the corresponding service settings. This guide covers the complete certificate lifecycle - from creating an internal CA to automating public certificate issuance through Let's Encrypt.

## Certificate Manager Structure

The Certificate Manager is divided into three tabs, each responsible for a separate PKI component.

| Tab | Purpose |
|---|---|
| Authorities | Certificate Authority (CA) management |
| Certificates | Server and client certificate management |
| Certificate Revocation | Certificate Revocation List (CRL) management |

Navigate between tabs from **System > Certificates**. Each component can be created locally or imported from an external source.

## Creating an Internal Certificate Authority

An internal CA (Certificate Authority) serves as the root trust anchor for the entire PKI. All certificates signed by this CA will be accepted by pfSense services configured to trust it.

### CA Creation Procedure

1. Navigate to **System > Certificates**, tab **Authorities**
2. Click **Add** to create a new CA
3. Fill in the parameters:

| Parameter | Value | Description |
|---|---|---|
| Descriptive name | Internal-CA | Arbitrary name for identification in the interface |
| Method | Create an internal Certificate Authority | Creates a new self-signed CA |
| Key type | RSA | Cryptographic key type |
| Key length | 2048 or 4096 | Key length in bits. 4096 provides stronger cryptographic protection |
| Digest Algorithm | SHA256 | Hashing algorithm for signatures |
| Lifetime | 3650 | CA validity period in days (10 years) |
| Common Name | internal-ca | Unique CA identifier in CN format |
| Country Code | US | Country code (ISO 3166-1 alpha-2) |
| State/Province | California | State or province |
| City | San Francisco | City |
| Organization | Company Name | Organization name |

4. Click **Save** to create the CA

After creation, export the CA certificate (without the private key) and install it on client devices to establish trust. Export is performed by clicking the download icon next to the CA in the list.

### Intermediate CAs

pfSense supports creating intermediate CAs signed by the root CA. This allows building a chain of trust and limiting the scope of certificate usage. To create an intermediate CA, select the method **Create an intermediate Certificate Authority** and specify the parent CA.

It is recommended to create separate CAs for different purposes:

- A CA for OpenVPN connections
- A CA for IPsec VPN
- A CA for the web interface and internal services

This separation provides isolation - revocation or compromise of one CA does not affect certificates issued by other CAs.

## Creating Server Certificates

Server certificates identify pfSense services to connecting clients. Typical use cases include securing the web GUI (HTTPS), the OpenVPN server endpoint, and IPsec authentication.

### Server Certificate Creation Procedure

1. Navigate to **System > Certificates**, tab **Certificates**
2. Click **Add/Sign**
3. Fill in the parameters:

| Parameter | Value | Description |
|---|---|---|
| Method | Create an internal Certificate | Creates a new certificate |
| Descriptive name | WebGUI-Cert | Name for identification in the interface |
| Certificate authority | Internal-CA | CA that will sign this certificate |
| Key type | RSA | Key type |
| Key length | 2048 | Key length |
| Digest Algorithm | SHA256 | Hashing algorithm |
| Lifetime | 398 | Validity period in days |
| Common Name | firewall.example.com | Server FQDN |
| Certificate Type | Server Certificate | Certificate type |

4. In the **Alternative Names** section, add all DNS names and IP addresses through which the service will be accessible
5. Click **Save**

> **Warning**:
>
> Modern browsers require a Subject Alternative Name (SAN) in the certificate. The Common Name (CN) field is only used as a fallback by legacy clients. Add FQDNs and IP addresses to the Alternative Names section.

### Assigning the Certificate to the Web GUI

After creating a server certificate, assign it to the web interface:

1. Navigate to **System > Advanced**, tab **Admin Access**
2. In the **SSL/TLS Certificate** field, select the newly created certificate
3. Click **Save**
4. The web interface will reload with the new certificate

### Server Certificate Validity Period

Apple and other browser vendors limit the maximum validity period of public TLS certificates to 398 days. Although this restriction is not mandatory for internal certificates, adhering to similar timeframes is recommended to simplify rotation and reduce compromise risks.

## Creating Client Certificates

Client certificates authenticate users when connecting to VPN services (OpenVPN, IPsec) and when accessing resources through the Captive Portal.

### Client Certificate Creation Procedure

1. Navigate to **System > Certificates**, tab **Certificates**
2. Click **Add/Sign**
3. Fill in the parameters:

| Parameter | Value | Description |
|---|---|---|
| Method | Create an internal Certificate | Creates a new certificate |
| Descriptive name | user-jsmith | Username or device identifier |
| Certificate authority | VPN-CA | CA for VPN certificates |
| Key type | RSA | Key type |
| Key length | 2048 | Key length |
| Digest Algorithm | SHA256 | Hashing algorithm |
| Lifetime | 365 | Validity period (1 year) |
| Common Name | user-jsmith | User identifier |
| Certificate Type | User Certificate | Certificate type |

4. Click **Save**

When using OpenVPN, a client certificate can be bound to a user account in User Manager. This provides two-factor authentication - the certificate (something the user has) and a password (something the user knows).

### Creating a Certificate via User Manager

An alternative method for creating client certificates is through the user account:

1. Navigate to **System > User Manager**
2. Edit the user account
3. In the **User Certificates** section, click **Add**
4. Fill in the certificate parameters
5. Save

This method automatically binds the certificate to the user, simplifying management when dealing with a large number of VPN users.

## Importing External Certificates

pfSense allows importing certificates obtained from external Certificate Authorities (DigiCert, Sectigo, Let's Encrypt, and others). Import is necessary in the following cases:

- Using publicly trusted certificates for the web interface
- Integrating with enterprise PKI
- Migrating from another firewall

### CA Import Procedure

1. Navigate to **System > Certificates**, tab **Authorities**
2. Click **Add**
3. Select the method **Import an existing Certificate Authority**
4. Paste the CA certificate in PEM format into the **Certificate data** field
5. Optionally import the CA private key (required for signing new certificates)
6. Click **Save**

### Certificate Import Procedure

1. Navigate to **System > Certificates**, tab **Certificates**
2. Click **Add/Sign**
3. Select the method **Import an existing Certificate**
4. Paste the certificate in PEM format into the **Certificate data** field
5. Paste the private key into the **Private key data** field
6. Click **Save**

> **Warning**:
>
> The private key must not be passphrase-protected. If the key is encrypted, remove the protection beforehand using `openssl rsa -in encrypted.key -out decrypted.key`.

## Certificate Revocation Lists (CRL)

A Certificate Revocation List (CRL) is a mechanism for revoking compromised or invalid certificates. When a client connects, the service checks the certificate against the CRL and rejects the connection if the certificate has been revoked.

### Creating a CRL

1. Navigate to **System > Certificates**, tab **Certificate Revocation**
2. Click **Add** next to the relevant CA
3. Select the method **Create an internal Certificate Revocation List**
4. Specify a CRL name
5. Click **Save**

### Revoking a Certificate

1. Open the CRL for editing
2. In the **Choose a Certificate to Revoke** section, select the certificate
3. Specify the revocation reason (Key Compromise, CA Compromise, Cessation of Operation, etc.)
4. Click **Add**

After revocation, all active connections using that certificate will be terminated at the next CRL check. For OpenVPN, this occurs during TLS session renegotiation.

### Binding a CRL to Services

A CRL must be explicitly bound to a service to activate revocation checking:

- **OpenVPN**: in the server settings, **Peer Certificate Revocation List** field
- **IPsec**: CRL checking is configured in Phase 1 parameters

Without binding a CRL to a service, revoked certificates will continue to be accepted.

## ACME Package for Let's Encrypt

ACME (Automated Certificate Management Environment) is a protocol for automated certificate issuance and renewal from public CAs. The ACME package for pfSense automates obtaining free TLS certificates from Let's Encrypt.

### Installing the ACME Package

1. Navigate to **System > Package Manager**, tab **Available Packages**
2. Search for the **acme** package
3. Click **Install** and confirm the installation

After installation, the package is accessible from **Services > Acme Certificates**.

### Registering a Let's Encrypt Account

1. Navigate to **Services > Acme Certificates**, tab **Account Keys**
2. Click **Add**
3. Fill in the parameters:

| Parameter | Value |
|---|---|
| Name | LetsEncrypt-Prod |
| ACME Server | Let's Encrypt Production ACME v2 |
| Email Address | admin@example.com |

4. Click **Create new account key**
5. Click **Register ACME account key**
6. Click **Save**

For testing purposes, use **Let's Encrypt Staging** first to avoid rate limiting.

### Creating a Certificate via ACME

1. Navigate to the **Certificates** tab
2. Click **Add**
3. Fill in the parameters:

| Parameter | Value | Description |
|---|---|---|
| Name | firewall-acme | Certificate name |
| Status | Active | Status |
| Acme Account | LetsEncrypt-Prod | Previously created account |
| Private Key | 2048-bit RSA | Key type and length |
| Domain SAN list | firewall.example.com | List of domain names |

4. In the **Domain SAN list** section, select the validation method:

| Validation Method | When to Use |
|---|---|
| Standalone HTTP server | Port 80 is accessible from the internet, no web server running |
| Standalone TLS-ALPN | Port 443 is accessible, no other TLS services |
| DNS-Manual | Manual DNS record creation (not suitable for automation) |
| DNS-Cloudflare/Route53/etc. | Automatic DNS validation via provider API |

5. Click **Save**
6. Click **Issue/Renew** to obtain the certificate

### Automatic Renewal

The ACME package automatically creates a cron job for certificate renewal. By default, the check runs daily, and the certificate is renewed when the expiration date is within 30 days.

To apply the renewed certificate to the web interface, enable the **ACME Renewal** option in the certificate settings and select **Restart webConfigurator** in the **Actions list** field.

### Wildcard Certificates

Let's Encrypt supports wildcard certificates (*.example.com), but only through DNS validation. HTTP validation is not available for wildcard certificates. Integration with the DNS provider API must be configured.

## Where Certificates Are Used

Certificates managed through the Certificate Manager are used across the following pfSense components.

| Component | Certificate Type | Purpose |
|---|---|---|
| Web GUI | Server | HTTPS access to the web interface |
| OpenVPN Server | Server | Server identification to connecting clients |
| OpenVPN Client | Client | User authentication to the server |
| IPsec | Server/Client | VPN tunnel participant authentication |
| Captive Portal | Server | HTTPS authorization portal |
| HAProxy | Server | TLS termination at the load balancer |
| LDAP Auth | CA | LDAP server verification during connection |
| Syslog (TLS) | Server/CA | Log transmission encryption |

## Renewal and Rotation

### Manual Renewal

When a certificate approaches its expiration date, create a new certificate with the same parameters and replace the old one in all services that use it. pfSense displays expiration dates in the certificate list and warns about expiring certificates on the Dashboard.

### Rotation Recommendations

| Certificate Type | Recommended Lifetime | Rationale |
|---|---|---|
| CA | 10-20 years | CA replacement requires reissuing all certificates |
| Server | 1-2 years | Compliance with browser requirements |
| Client | 1 year | Regular rotation to reduce risk |
| ACME (Let's Encrypt) | 90 days (automatic) | Set by Let's Encrypt |

### Expiration Monitoring

pfSense displays certificate status in the web interface:

- Green - certificate is valid
- Yellow - certificate expires within 30 days
- Red - certificate has expired

Consider configuring monitoring through SNMP or [Wazuh integration](/docs/pfsense/pfsense-wazuh-integration/) for automated alerts on expiring certificates.

## Troubleshooting

### "Certificate chain is incomplete" Error

This problem occurs when the client cannot build a trust chain from the server certificate to the root CA.

Resolution:

1. Verify that the CA certificate is installed on the client device
2. When using an intermediate CA, ensure the full chain (intermediate + root CA) is delivered to the client
3. Confirm that the correct CA is specified in the service settings

### "Certificate has expired" Error

A certificate past its validity period is rejected by clients and services.

Resolution:

1. Create a new certificate with current validity dates
2. Replace the certificate in all services that use it
3. Restart the services to apply the new certificate

### "NET::ERR_CERT_AUTHORITY_INVALID" Error

The browser does not trust the CA that issued the certificate.

Resolution for an internal CA:

1. Export the CA certificate from pfSense
2. Install it in the operating system or browser trusted root certificate store
3. Restart the browser

### OpenVPN Rejects the Certificate

This problem can be caused by several issues:

- The certificate type (Server/User) does not match the VPN role
- The certificate was signed by a CA different from the one specified in OpenVPN settings
- The certificate has been revoked via CRL

For diagnostics, check the OpenVPN logs under **Status > System Logs**, tab **OpenVPN**.

## Migration Notes

When migrating from another firewall or upgrading pfSense, consider the following:

- Export all CAs, certificates, and CRLs before migration
- Certificates are exported in PEM format via the download icon in Certificate Manager
- Private keys are exported separately and must be stored securely
- After import, certificates must be re-bound to services (OpenVPN, IPsec, Web GUI)
- A pfSense configuration backup includes all certificates and keys - when [restoring from a backup](/docs/pfsense/backup/pfsense-backup-recovery/), re-importing is not necessary

## Related Sections

- [VPN - OpenVPN](/docs/pfsense/vpn/openvpn/) - configuring OpenVPN with certificate-based authentication
- [User Management](/docs/pfsense/users/pfsense-user-management/) - binding certificates to user accounts
- [Backup and Recovery](/docs/pfsense/backup/pfsense-backup-recovery/) - configuration backup including certificates