Feature Request: Auto-import self-signed certificates to system trust store

[amitu]

Feature Request: Auto-import self-signed certificates to system trust store

Problem Statement

Currently, fastn-rig generates self-signed certificates for STARTTLS email protocols, but users must manually trust these certificates in their email clients (Apple Mail, Thunderbird, etc.). This creates friction for:

1. End users - Manual certificate trust is error-prone and confusing
2. E2E testing - Real email client testing requires manual certificate setup
3. Development - Certificate warnings break automated testing workflows

Current Certificate Architecture Analysis

Based on code review of fastn-rig/src/certs/:

✅ What works:

• Self-signed cert generation using rig's Ed25519 key (self_signed.rs:87-144)
• Per-IP certificate storage in fastn_home.parent()/certs/self-signed/
• Subject Alternative Names include localhost, 127.0.0.1, public IP, hostname, domain
• TLS configuration for STARTTLS SMTP server

❌ Current gaps:

• Filesystem save/load incomplete (filesystem.rs:175-198 - stubs only)
• No certificate export functionality for external use
• Manual trust required for email clients
• No verification that certificates are properly trusted

Proposed Solution

New CLI Command: fastn-rig trust-cert

```bash

Auto-import certificate to system trust store

fastn-rig trust-cert

With verification tests

fastn-rig trust-cert --verify

Export certificate without importing

fastn-rig trust-cert --export-only --output ~/fastn-cert.pem
```

Cross-Platform Implementation Plan

macOS Support

```bash

User keychain (no sudo required)

security add-trusted-cert -d -r trustRoot -k ~/Library/Keychains/login.keychain cert.pem

System keychain (requires sudo)

sudo security add-trusted-cert -d -r trustAsRoot -k /Library/Keychains/System.keychain cert.pem
```

Linux Support

```bash

Ubuntu/Debian

sudo cp cert.pem /usr/local/share/ca-certificates/fastn-rig.crt
sudo update-ca-certificates

RHEL/CentOS

sudo cp cert.pem /etc/pki/ca-trust/source/anchors/fastn-rig.crt
sudo update-ca-trust
```

Windows Support

```powershell

PowerShell as Administrator

Import-Certificate -FilePath "cert.pem" -CertStoreLocation "Cert:\LocalMachine\Root"
```

SSL Verification Strategy

After certificate import, verify trust with multiple methods:

1. curl test: `curl -v https://localhost:587/\` (should show trusted cert)
2. openssl test: `openssl s_client -connect localhost:587 -starttls smtp`
3. fastn-mail test: Internal SMTP connection without warnings
4. Native TLS test: Rust reqwest/rustls validation

Implementation Architecture

```rust
// New module: fastn-rig/src/certs/trust.rs
pub struct CertificateTrustManager {
cert_storage: CertificateStorage,
os_detector: OsDetector,
}

impl CertificateTrustManager {
pub async fn install_certificate(&self) -> Result<(), CertError> {
// 1. Export certificate to temp file
// 2. Detect OS and call appropriate install command
// 3. Verify installation with SSL tests
// 4. Clean up temp files
}

pub async fn verify_certificate_trust(&self) -> Result<TrustStatus, CertError> {
    // Run comprehensive SSL verification tests
}

}
```

User Experience Flow

1. Development: `fastn-rig trust-cert` during setup
2. E2E Testing: Automated certificate trust in CI/CD
3. End Users: One-time certificate installation with verification

Benefits

• Improved UX: No more manual certificate trust steps
• Better Testing: Real email client testing without warnings
• Cross-Platform: Consistent experience across macOS/Linux/Windows
• Verification: Automated testing ensures certificates work properly
• Automation-Friendly: Scriptable for CI/CD workflows

Questions for Discussion

1. Should we default to user keychain or system keychain on macOS?
2. How to handle sudo requirements gracefully?
3. Should certificate trust be part of `fastn-rig run` or separate command?
4. What verification tests are most important?
5. How to handle certificate rotation/updates?

Implementation Timeline

1. Phase 1: Complete filesystem certificate storage
2. Phase 2: Add certificate export functionality
3. Phase 3: Implement macOS trust automation
4. Phase 4: Add Linux/Windows support
5. Phase 5: SSL verification testing
6. Phase 6: Integration with existing workflows

Thoughts and feedback welcome! 🚀