kpcyrd / acme-redirect Goto Github PK

View Code? Open in Web Editor NEW

70.0 7.0 11.0 269 KB

Tiny http daemon that answers acme challenges and redirects everything else to https

License: GNU General Public License v3.0

Dockerfile 1.06% Shell 4.93% Rust 93.74% Makefile 0.27%

acme-redirect's Introduction

acme-redirect(1)

A tiny http daemon that answers acme challenges and redirects everything else to https.

A minimal configuration looks like this:

# cat /etc/acme-redirect.d/example.com.conf
[cert]
name = "example.com"
dns_names = [
    "example.com",
    "www.example.com",
]
exec = [
    "systemctl reload nginx",
]

You don't need to edit anything else. Start the acme-redirect daemon:

systemctl enable --now acme-redirect

Ensure the service is running correctly and the redirect works as expected. Ensure your A and AAAA records point to the right server and check everything is working correctly by fetching a random proof from our local daemon.

acme-redirect check

If OK is displayed for every name you can request a real certificates:

acme-redirect renew

If this succeeded you should setup automatic renew:

systemctl enable --now acme-redirect-renew.timer

The certificate is located here:

/var/lib/acme-redirect/live/example.com/fullchain
/var/lib/acme-redirect/live/example.com/privkey

Example configuration looks like this:

nginx

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    ssl_certificate /var/lib/acme-redirect/live/example.com/fullchain;
    ssl_certificate_key /var/lib/acme-redirect/live/example.com/privkey;
    ssl_session_timeout 1d;
    ssl_session_cache shared:MozSSL:10m;  # about 40000 sessions
    ssl_session_tickets off;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;

    add_header Strict-Transport-Security "max-age=63072000" always;

    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /var/lib/acme-redirect/live/example.com/chain;
    resolver 127.0.0.1;

    # ...
}

apache

<VirtualHost *:443>
    SSLEngine on

    SSLCertificateFile /var/lib/acme-redirect/live/example.com/fullchain
    SSLCertificateKeyFile /var/lib/acme-redirect/live/example.com/privkey

    Protocols h2 http/1.1
    Header always set Strict-Transport-Security "max-age=63072000"
</VirtualHost>

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder     off
SSLSessionTickets       off

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

lighttpd

server.modules += ("mod_openssl")
$SERVER["socket"] == "0.0.0.0:443" {
    ssl.engine = "enable"
    ssl.privkey= "/var/lib/acme-redirect/live/example.com/privkey"
    ssl.pemfile= "/var/lib/acme-redirect/live/example.com/fullchain"
    ssl.openssl.ssl-conf-cmd = ("MinProtocol" => "TLSv1.2")
    #ssl.ca-file= "/var/lib/acme-redirect/live/example.com/chain" # (needed in $SERVER["socket"] before lighttpd 1.4.56 if ssl.pemfile in $HTTP["host"])
}

Installation

Arch Linux

pacman -S acme-redirect

Debian based

Currently supported: buster

apt install debian-keyring
gpg -a --export --keyring /usr/share/keyrings/debian-maintainers.gpg [email protected] | apt-key add -
apt-key adv --keyserver keyserver.ubuntu.com --refresh-keys [email protected]
echo deb https://apt.vulns.sexy stable main >> /etc/apt/sources.list.d/apt-vulns-sexy.list
apt update && apt install acme-redirect

Build from source

git clone https://github.com/kpcyrd/acme-redirect.git
cd acme-redirect/
cargo build --release

install -Dm 755 -t /usr/bin \
    target/release/acme-redirect

install -Dm 644 contrib/confs/acme-redirect.conf -t /etc
install -Dm 644 contrib/confs/certs.d/example.com.conf /etc/acme-redirect.d/example.com.conf.sample

install -Dm 644 -t /etc/systemd/system \
    contrib/systemd/acme-redirect-renew.service \
    contrib/systemd/acme-redirect-renew.timer \
    contrib/systemd/acme-redirect.service
install -Dm 644 contrib/systemd/acme-redirect.sysusers /etc/sysusers.d/acme-redirect.conf
install -Dm 644 contrib/systemd/acme-redirect.tmpfiles /etc/tmpfiles.d/acme-redirect.conf

sudo systemd-sysusers
sudo systemd-tmpfiles --create

Status

I'm using this in production since summer 2020 (northern hemisphere, around May).

Development

mkdir -vp tmp/challs
export ACME_CONFIG="$PWD/contrib/confs/acme-redirect.conf"
export ACME_CONFIG_DIR="$PWD/contrib/confs/certs.d/"
export ACME_CHALL_DIR="$PWD/tmp/"
export ACME_DATA_DIR="$PWD/tmp/"

cargo run -- status
cargo run -- daemon -B '[::]:8080' -v

boxxy

acme-redirect uses setuid and chroot to drop privileges before accepting requests. This can be inspected with boxxy.

mkdir -vp tmp/web
sudo chown root. tmp/web
cargo build --examples
(cd tmp/web && sudo ../../target/debug/examples/boxxy)

License

GPLv3+

acme-redirect's People

Contributors

Stargazers

Watchers

Forkers

atul9 aaron1011 alerque isgasho datahenge guddaff suryatmodulus cyqsimon kursh durkadurr franklx

acme-redirect's Issues

Compatibility with OpenSSL 3.x -> cannot install with Debian 12 Bookworm

When trying to install the package under Debian 12 Bookworm:

apt update && apt install acme-redirect
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://deb.debian.org/debian bookworm-updates InRelease
Hit:3 http://deb.debian.org/debian-security bookworm-security InRelease
Get:4 https://apt.vulns.sexy stable InRelease [1,804 B]
Get:5 https://apt.vulns.sexy stable/main amd64 Packages [1,376 B]
Fetched 3,180 B in 1s (2,978 B/s)    
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
W: https://apt.vulns.sexy/dists/stable/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 **acme-redirect : Depends: libssl1.1 (>= 1.1.0) but it is not installable**
E: Unable to correct problems, you have held broken packages.

Debian 12 Bookworm uses OpenSSL 3.0.x, as OpenSSL 1.1.1 is no longer maintained for this distro + will be EoL in September 11th 2023

Is there any workaround or update to keep using acme-redirect ?

Thanks.

pre-hook

Would it be possible to implement a pre-hook script, as certbot does?
Thanks.

RPM package for Fedora & RHEL family

Built here: https://copr.fedorainfracloud.org/coprs/cyqsimon/acme-redirect/

Makes life easier for guys like me running RedHat servers

You can find the spec file's source here: https://github.com/cyqsimon/acme-redirect-spec

Installation instructions

dnf copr enable cyqsimon/acme-redirect
dnf install acme-redirect

Prefer 0440 over 0640 during renew

Not much of a change, but the write bit for the owner shouldn't be necessary, so we shouldn't set it when writing the new certificate to disk.

Create file with certificate and private key combined (lighttpd)

Lighttpd seems to prefer the certificate in this format. This currently requires scripting in the exec hooks.

Allow certificate storage data dir to be permanently configured

Right now the data dir seems to rely on either the default or run time flags. This does mean it can be set in a systemd service, but that makes changing the location difficult when installed from system packages. It also means every invocation from the CLI needs the matching data argument.

I suggest a certificate_dir or similar key in the [acme] section of the global config. This would simplify the necessary service files and allow CLI usage without flagging it every time. Moving the data dir out of /var/lib will be far more common than moving the system config file out of /etc.

Create file with ca certificate chain

mosquitto wants a file that contains only the CA chain. acme-redirect should create this file when writing the certificate to disk.

Keys for apt-get need to be updated

Err:5 https://apt.vulns.sexy stable InRelease
The following signatures were invalid: EXPKEYSIG 45A650E2638C536D kpcyrd [email protected]
Fetched 14.0 kB in 1s (10.3 kB/s)
Reading package lists... Done
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://apt.vulns.sexy stable InRelease: The following signatures were invalid: EXPKEYSIG 45A650E2638C536D kpcyrd [email protected]
W: Failed to fetch https://apt.vulns.sexy/dists/stable/InRelease The following signatures were invalid: EXPKEYSIG 45A650E2638C536D kpcyrd [email protected]
W: Some index files failed to download. They have been ignored, or old ones used instead.

Force certificate renew

Currently there is no way to force a renew of certificates when they are not expired. This is needed when the configuration changes (e.g. adding a new subdomain).

Global hooks, exec= in /etc/acme-redirect.conf

Maintaining a list of exec hooks for every certificate can be tedious, instead we should have an extra list that applies to every certificate config in addition to individual configuration. Things like reloading nginx could qualify as a global hook.

Certificate access by group

There are currently two places where the group is relevant:

/var/lib/acme-redirect/ - systemd-tempfiles or openrc create this folder owned by acme-redirect:acme-redirect and 0750.
/var/lib/acme-redirect/certs/*/privkey - created during renew and is set to 0640. Since you're likely to need root for your reload hooks the group for this file is likely to end up as root.

Services usually load the configuration privileged so this is not an issue, but they may need to be part of a specific group that is then granted access to /var/lib/acme-redirect/ and /var/lib/acme-redirect/certs/*/privkey.

The config should have an optional value that (if set) enforces a specific group if the group wasn't already set correctly during creation. The default configuration should set this to acme-redirect to match existing setups (development is going to need a different config), even if the renew is executed in unprivileged mode. If renew is executed by root we have the permissions necessary to update the group accordingly.

Our config value should be used for both of them, to ensure acme-redirect and systemd-tempfiles don't change this back and forth. /var/lib/acme-redirect/ can only be created with root permissions, so this is going to be done during the daemon setup (which is the most reliable way for us to ensure the setup can be done as root).

The owner for this folder is going to be:

set according to the --user option in acme-redirect daemon if set
left as-is if it isn't set
if it doesn't exist we're going to create it with the owner being the current user (which is likely to be root)

Creating the folder with openrc or systemd-tempfiles isn't necessary afterwards.

Are wildcard subdomains supported?

If so, how to do so should probably be documented.

If not, can they be?

My use case is trying to setup an Apache HTTPS proxy in front of a GitLab Pages daemon. The latter has it's own certificate handling built in but using it requires running it on both port 80 and 443. That of course is precluded by my having only a single IP to work with, running acme-redirect on port 80 and Apache on 443 (with a mix of native sites and proxies to other daemons).

If it matters, by hope would be to get a wildcard cert for sub-sub domains (the main domain for my pages instance being itself a subdomain). If that's not possible of course a regular subdomain wildcard could work, I'd just have to purpose a new domain for it.

Pure Rust implementation?

Hi. Is it possible to provide a pure Rust-based generation of certificates (that avoids openssl)? There seem to be libraries/apps that generate certificates using Rust already: https://crates.io/crates/certainly

Avoiding openssl makes sense for users who are worried about openssl vulnerabilities and [unnecessary] complexity.

Using the pure-rust implementation could then be hidden under a feature flag if openssl is desired to be used by default.