Automatic SSL certificate from Let's Encrypt

[thebe14]

Supports HTTPS with either an automatically obtained certificate or a manually supplied one.

Closes #94

[t-book]

I was just before creating a PR for https over LE. So +1 for this. @kowh-ai
As this PR is already a bit older? Any plans that this gets merged?

In case of interest this is the entrypoint I would have come up to. It supports requesting

• localhost
• staging (higher rate limits for testing)
• production

and keeps the current naming of certs, in case backwards compatibility somehow counts

#!/bin/sh

# Exit script in case of error
set -e

echo $"\n\n\n"
echo "-----------------------------------------------------"
echo "STARTING LETSENCRYPT ENTRYPOINT ---------------------"
date

# Check for initial certificate request and setup based on mode
PRIMARY_DOMAIN=$(echo $DOMAINS | cut -d ',' -f1)

DOMAINS_ARG=""
for DOMAIN in $(echo $DOMAINS | tr "," "\n"); do
    DOMAINS_ARG="$DOMAINS_ARG -d $DOMAIN"
done

obtain_or_renew_certificates() {
    echo "Attempting to obtain or renew certificates..."
    BEFORE_RENEWAL=$(stat -c %Y "/etc/letsencrypt/live/$PRIMARY_DOMAIN/fullchain.pem" 2>/dev/null || echo 0)

    # Introduce forced renewal if FORCE_RENEWAL is set to true
    FORCE_RENEWAL_ARG=""
    if [ "$FORCE_RENEWAL" = "true" ]; then
        FORCE_RENEWAL_ARG="--force-renewal"
        echo "Forced renewal is enabled."
    fi

    # Handle different LETSENCRYPT_MODEs
    case "$LETSENCRYPT_MODE" in
        "staging")
            certbot renew --quiet $FORCE_RENEWAL_ARG || certbot certonly --standalone --preferred-challenges http --email $EMAIL --agree-tos --no-eff-email --test-cert $DOMAINS_ARG
            ;;
        "production")
            certbot renew --quiet $FORCE_RENEWAL_ARG || certbot certonly --standalone --preferred-challenges http --email $EMAIL --agree-tos --no-eff-email $DOMAINS_ARG
            ;;
        "localhost")
            if [ "$FORCE_RENEWAL" = "true" ]; then
                # Generate a new self-signed certificate for localhost
                openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout "/etc/nginx/certs/ckan-local.key" -out "/etc/nginx/certs/ckan-local.crt" -subj "/CN=localhost"
            else
                echo "Localhost mode: Skipping renewal since FORCE_RENEWAL is not true."
            fi
            return 0
            ;;
        *)
            echo "Invalid LETSENCRYPT_MODE. Exiting."
            exit 1
            ;;
    esac

    AFTER_RENEWAL=$(stat -c %Y "/etc/letsencrypt/live/$PRIMARY_DOMAIN/fullchain.pem" 2>/dev/null || echo 0)

    if [ "$AFTER_RENEWAL" -gt "$BEFORE_RENEWAL" ] || [ "$FORCE_RENEWAL" = "true" ]; then
        if [ -d "/etc/letsencrypt/live/$PRIMARY_DOMAIN" ]; then
            cp "/etc/letsencrypt/live/$PRIMARY_DOMAIN/fullchain.pem" "/etc/nginx/certs/ckan-local.crt"
            cp "/etc/letsencrypt/live/$PRIMARY_DOMAIN/privkey.pem" "/etc/nginx/certs/ckan-local.key"
            echo "Certificates were renewed and copied to Nginx directory."
        else
            echo "Certificate directory for $PRIMARY_DOMAIN does not exist."
        fi
    else
        echo "Certificates have not been renewed."
    fi
}


# Delete logs older than 1 month
echo "Deleting logs older than 1 month..."
find /var/log/letsencrypt -type f \( -name "*.log" -o -name "*.log.*" \) -mtime +30 -exec rm {} \;

# Run on container start
obtain_or_renew_certificates

# Start cron in foreground
exec crond -n

echo "-----------------------------------------------------"
echo "FINISHED LETSENCRYPT ENTRYPOINT ---------------------"
echo "-----------------------------------------------------"

[wardi]

We're discussing the direction for this ckan-docker repository maintained by the core ckan dev team. Currently:

• none of the core team is using this docker compose configuration in production
• only two members use this docker compose configuration for development
• most of the issues and support requests are related to using ckan-docker in production

Should we drop the docker-compose.yml file and production instructions instead of adding more production features to this docker compose configuration? (The repository is still useful for getting quickly started in development)

Should we leave docker-compose.yml there and warn that it is a starting point for people interested in creating their own docker compose configurations but is not supported by the core dev team?