# HTTPS Certificate Security

Duplicati can automatically generate HTTPS certificates for secure web UI access. This section documents the security model and best practices.

## Certificate Approach

Browsers currently reject certificates that have a validity period for more than 90 days, with the logic that rotation should be frequent and automated to prevent long-term exposure to potential vulnerabilities. Since Duplicati uses localhost serving by default, there is no Certificate Authority (CA) to request certificates from.

If Duplicati creates a self-signed certificate, it will would need to be re-authorized after 90 days, which would require admin permissions and possibly manual intervention every 90 days. To avoid this, Duplicati generates its own Certificate Authority (CA) and uses it to sign server certificates.

The CA private key is stored in the Duplicati database file, which is encrypted with the database encryption key. When a new certificate is needed, Duplicati generates a new certificate signed by the CA. Since the CA is local and not shared with any external service, this approach provides a secure way to manage certificates without requiring external dependencies. As the CA is trusted by the user or system, this enables Duplicati to automatically renew certificates without user intervention, in a way that is trusted by the user's browser.

Be aware that while the CA is local, it is still a CA and can be used to sign certificates for other domains. If someone gains access to the Duplicati database, they can use the CA to sign certificates for other domains, essentially providing an undetected man-in-the-middle attack.

If you prefer providing your own certificate, you can do so by setting the `server-ssl-certificate` and `server-ssl-certificatepassword` settings. This will not activate auto-renewal or generate a CA.

## Certificate Authority (CA) Security Model

When HTTPS is configured, Duplicati creates a local Certificate Authority (CA) with the following security properties:

### Local-Only CA

- The CA is generated locally on your machine and is not shared with any external service
- The CA certificate is installed only in your system's local trust store
- Other machines do not trust this CA unless explicitly configured to do so
- The CA should never be exported or shared with other systems, unless you understand the security implications

### pathLenConstraint=0

The CA certificate has `pathLenConstraint=0` in its Basic Constraints extension, which means:

- The CA can sign end-entity (server) certificates
- The CA **cannot** sign subordinate/intermediate CA certificates
- This limits the scope of trust to only the certificates directly signed by this CA

### Certificate Validity Periods

- **CA Certificate:** Valid for approximately 10 years
- **Server Certificate:** Valid for 90 days
- **Auto-renewal:** Server certificates are automatically renewed 30 days before expiration

## CA Key Storage Security

The CA private key is stored with multiple layers of protection:

1. **Encryption:** The private key is encrypted using AES-256-GCM with a password-derived key (PBKDF2 with 100,000 iterations)
2. **Password Separation:** The encryption password is stored separately from the encrypted key
3. **Database Encryption:** If database field encryption is enabled, an additional encryption layer is applied

**Important:** The security of your HTTPS certificates depends on the security of your Duplicati database file.

## Database Encryption Recommendation

For maximum security, enable database field encryption

```bash
# During initial setup
duplicati-server --settings-encryption-key=<strong-password>

# Or via environment variable
export DUPLICATI__SETTINGS_ENCRYPTION_KEY=<strong-password>
```

When database encryption is enabled:

- Sensitive settings, including certificate data, receive additional encryption
- A warning notification is avoided (the system emits a warning if certificates are stored without database encryption)
- The encryption key is derived from your server passphrase

## Revocation and Compromise Response

If you suspect your CA private key has been compromised:

1. **Immediate Action:** Remove the certificates using `duplicati-configure https remove`
2. **Regenerate:** Create a new CA with `duplicati-configure https regenerate-ca`
3. **Review:** Check recent server logs and backup history for unauthorized access
4. **Monitor:** Set up alerts for unexpected certificate changes

## Trust Store Installation

The CA certificate is installed in platform-specific trust stores:

- **Windows:** `Cert:\CurrentUser\Root` (or `Cert:\LocalMachine\Root` when run as Administrator)
- **Linux:** Distribution-specific paths (`/usr/local/share/ca-certificates/`, `/etc/pki/ca-trust/source/anchors/`, etc.)
- **macOS:** System keychain via `security add-trusted-cert`

**Security Note:** Installing a CA in the system trust store gives it broad trust. While the Duplicati CA is constrained (pathLenConstraint=0, no sub-CAs), you should:

- Only install CAs you trust
- Remove the CA when no longer needed (`duplicati-configure https remove`)
- Be cautious of any CA installation prompts from unknown sources
- Understand that access to the generated CA private key will allow signing arbitrary certificates, defeating any TLS/SSL/https security for your machine

## Certificate Pinning Considerations

For high-security environments, consider implementing certificate pinning:

- Extract the CA certificate thumbprint after generation
- Configure clients or monitoring systems to expect only this specific CA
- This prevents acceptance of certificates signed by other CAs that might be installed on the system

## Browser Trust (Chrome and Firefox on Linux)

While the CA certificate is installed in the system trust store, Chrome and Firefox on Linux maintain their own certificate stores and may not automatically trust the system CA. This is especially true for sandboxed installations (Snap, Flatpak).

### Exporting the CA Certificate

To manually import the CA into Chrome or Firefox, first export it using the ConfigureTool:

```bash
# Export to default filename (duplicati-ca.crt)
duplicati configure-tool https export-ca

# Or specify a custom output path
duplicati configure-tool https export-ca --file ~/Desktop/duplicati-ca.crt
```

### Importing to Firefox

1. Open Firefox and go to **Settings** → **Privacy & Security**
2. Scroll to **Certificates** and click **View Certificates**
3. Select the **Authorities** tab
4. Click **Import** and select the exported `duplicati-ca.crt` file
5. Check **"Trust this CA to identify websites"** and click OK

### Importing to Chrome

1. Open Chrome and go to **Settings** → **Privacy and security** → **Security**
2. Click **Manage certificates**
3. Select the **Authorities** tab
4. Click **Import** and select the exported `duplicati-ca.crt` file
5. Check **"Trust this certificate for identifying websites"** and click OK

**Note:** For Flatpak or Snap installations of Chrome/Firefox, the browsers run in a sandbox that may restrict file access. If you encounter "error reading file" during import, copy the certificate to a location accessible by the sandbox (e.g., `/tmp/`) before importing:

```bash
cp ~/duplicati-ca.crt /tmp/duplicati-ca.crt
chmod 644 /tmp/duplicati-ca.crt
# Then import from /tmp in the browser
```

### Avoiding system store trust

Since the certificates are not loaded from the system store anyway when using a Flatpak or Snap installation, you can avoid installing the CA in the system trust store. Apply the commandline option `--no-trust` when you generate the CA certificate:

```bash
duplicati configure-tool https generate --no-trust
```

This will generate a CA certificate that is not installed in the system trust store and does not require elevated privileges to install. Once the certificate is generated, you can export it and manually import it into your browser as described above.
