FreeScout SSL: Wildcard Certificates & Advanced Setup (2025)

After basic Let's Encrypt setup, you might need advanced SSL configurations: wildcard certificates for subdomains, internal PKI for private networks, or certificate pinning for security. This guide covers those scenarios.

When to Use Advanced SSL

Basic Let's Encrypt: Fine for most teams

• Single domain (freescout.your-domain.com)
• Public internet
• Standard validation

Advanced SSL: Required for:

• Wildcard subdomains (*.your-domain.com)
• Internal/private networks
• High-security requirements
• Multiple domains under one cert

Scenario 1: Wildcard Certificates

Wildcard certs cover all subdomains: *.your-domain.com matches app.your-domain.com, help.your-domain.com, etc.

Using Let's Encrypt Wildcard (DNS Challenge)

Let's Encrypt issues wildcards, but requires DNS validation (not HTTP).

sudo apt install -y python3-certbot-dns-cloudflare

(Or install the plugin for your DNS provider: Cloudflare, Route 53, DigitalOcean, etc.)

sudo certbot certonly --dns-cloudflare \
  -d your-domain.com \
  -d '*.your-domain.com'

Certbot will:

1. Ask for Cloudflare API credentials
2. Add TXT record to _acme-challenge.your-domain.com
3. Validate you own the domain
4. Issue wildcard certificate

Auto-renewal works automatically (Certbot handles DNS updates).

Available DNS Providers

# Cloudflare
pip install certbot-dns-cloudflare

# AWS Route 53
pip install certbot-dns-route53

# DigitalOcean
pip install certbot-dns-digitalocean

# Azure
pip install certbot-dns-azure

# Google Cloud
pip install certbot-dns-google

Scenario 2: Multi-Domain Certificates (SAN)

Subject Alternative Names (SAN) let one cert cover multiple domains:

Primary: freescout.your-domain.com
Alternative 1: help.your-domain.com
Alternative 2: support.your-domain.com

All covered by one certificate.

Issue Multi-Domain Cert

sudo certbot certonly --webroot -w /var/www/freescout/public \
  -d freescout.your-domain.com \
  -d help.your-domain.com \
  -d support.your-domain.com

Certificate will list all three domains in the SAN extension.

NGINX Configuration for Multiple Domains

Edit your NGINX config:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    
    server_name freescout.your-domain.com 
                help.your-domain.com 
                support.your-domain.com;

    ssl_certificate /etc/letsencrypt/live/freescout.your-domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/freescout.your-domain.com/privkey.pem;

    # ... rest of config
}

All three domains resolve to the same FreeScout instance.

Scenario 3: Internal/Private Network SSL

If FreeScout is on an internal network (not public internet), Let's Encrypt won't work (requires public DNS).

Solution: Self-Signed Certificates

Generate your own certificate:

# Generate private key
openssl genrsa -out /etc/ssl/private/freescout.key 2048

# Generate self-signed certificate (valid 1 year)
openssl req -new -x509 -key /etc/ssl/private/freescout.key \
  -out /etc/ssl/certs/freescout.crt -days 365 \
  -subj "/C=US/ST=State/L=City/O=Company/CN=freescout.internal"

Use in NGINX:

ssl_certificate /etc/ssl/certs/freescout.crt;
ssl_certificate_key /etc/ssl/private/freescout.key;

Problem: Browsers show "untrusted certificate" warnings.

Better Solution: Internal CA

Create your own Certificate Authority (CA):

# Generate CA private key
openssl genrsa -out ca.key 2048

# Generate CA certificate
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt \
  -subj "/C=US/ST=State/L=City/O=Company/CN=MyCompanyCA"

# Generate server CSR (Certificate Signing Request)
openssl req -new -key freescout.key -out freescout.csr \
  -subj "/C=US/ST=State/L=City/O=Company/CN=freescout.internal"

# Sign with your CA
openssl x509 -req -days 365 -in freescout.csr \
  -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out freescout.crt

Now: Install ca.crt on all client machines to trust your CA. Browsers will see a valid certificate.

Scenario 4: Certificate Pinning (High Security)

Certificate pinning prevents MITM attacks by pinning a specific certificate.

Pin Certificate Public Key

Add to NGINX:

add_header Public-Key-Pins 'pin-sha256="[base64 hash]"; max-age=31536000' always;

Generate the hash:

openssl x509 -in /etc/letsencrypt/live/freescout.your-domain.com/fullchain.pem \
  -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256 -binary | openssl enc -base64

This pins the public key for 1 year. Changing certs breaks clients (use with caution).

Scenario 5: Wildcard + Multi-Domain

Combine both approaches:

sudo certbot certonly --dns-cloudflare \
  -d your-domain.com \
  -d '*.your-domain.com' \
  -d help.your-domain.com \
  -d support.your-domain.com

One certificate covers:

• your-domain.com
• *.your-domain.com (all subdomains)
• help.your-domain.com
• support.your-domain.com

Perfect for multi-instance deployments.

Certificate Validation Methods

Let's Encrypt supports multiple validation types:

| Method | How It Works | Best For | |---|---|---| | HTTP | Places file in /.well-known/acme-challenge/ | Single domain, public internet | | DNS | Adds TXT record to DNS | Wildcard, multiple domains | | TLS-ALPN | ACME protocol negotiation | Advanced, rarely needed |

For wildcard: Use DNS. For single domain: Use HTTP (simpler).

Renewal & Automation

Manual Renewal (Should Be Automatic)

sudo certbot renew --force-renewal
sudo systemctl reload nginx

Verify Auto-Renewal is Set Up

sudo systemctl status certbot.timer
sudo certbot renew --dry-run

Should show "The following certificates were successfully renewed."

Renewal Notifications

Certbot emails you if renewal fails. Check your email regularly.

Common Advanced SSL Issues

| Issue | Cause | Fix | |---|---|---| | "Too many certificates for domain" | Issued 50+ certs/week for same domain | Wait one week, Let's Encrypt rate-limit resets | | "Invalid challenge" (DNS) | DNS record not propagated | Wait 5–10 minutes, try again | | "Self-signed cert" (internal) | CA cert not trusted | Install CA cert on client machines | | "Cert pinning breaks" | Updated certificate, old key not pinned | Plan certificate updates in advance | | "Wildcard won't validate" | Using HTTP validation (not supported) | Switch to DNS validation |

Certificate Monitoring

Check Certificate Expiry

echo | openssl s_client -servername your-domain.com \
  -connect your-domain.com:443 2>/dev/null | \
  openssl x509 -noout -dates

Or:

sudo certbot certificates

Set Expiry Reminder

Certbot sends emails 30 days before expiry. Add to monitoring:

# Check expiry weekly
0 9 * * 1 /usr/local/bin/check-ssl-expiry.sh

Script:

#!/bin/bash
DOMAIN="your-domain.com"
DAYS=$(echo | openssl s_client -servername $DOMAIN -connect $DOMAIN:443 2>/dev/null | openssl x509 -noout -dates | grep notAfter | awk -F= '{print $2}' | xargs -I {} date -d {} +%s)
NOW=$(date +%s)
DIFF=$((($DAYS - $NOW) / 86400))

if [ $DIFF -lt 14 ]; then
  echo "Certificate expiring in $DIFF days!" | mail -s "SSL Alert" admin@your-domain.com
fi

Best Practices

1. Start simple: Use Let's Encrypt HTTP validation
2. Use wildcard only if needed: Added complexity, DNS-dependent
3. Monitor expiry: Set alerts 30+ days in advance
4. Test renewal: Run certbot renew --dry-run monthly
5. Pin only if you understand consequences: Pinning breaks everything on certificate change
6. For internal networks: Use internal CA, not self-signed

Summary

Advanced SSL is for specific scenarios:

• Wildcard: Multiple subdomains
• Multi-domain: Multiple domains under one cert
• Internal PKI: Private networks
• Pinning: High-security requirements

Most FreeScout deployments use basic Let's Encrypt HTTP validation. Use advanced options only when necessary.

All FreeScout installations need SSL. Choose the right approach for your use case.

Resources

• Let's Encrypt Wildcard Certificates — wildcard SSL documentation
• Certbot DNS Plugins — DNS challenge plugins
• SSL Labs Test — verify your SSL configuration
• Cloudflare DNS API — for automated DNS challenges