Ubuntu 26.04 / HTTPS-Zertifikate ausstellen und Erneuerung sowie Ablauf überprüfen

Richten Sie HTTPS erst ein, nachdem Sie eine Domain, die Sie kontrollieren, und deren Validierungsroute vorbereitet haben. Die Zertifikatsausstellung, das tatsächlich extern bereitgestellte Zertifikat, die geplante Verlängerung und die Ablaufüberwachung sind separate Prüfpunkte.

Überprüfen Sie Domain- und öffentliche HTTP-Voraussetzungen

Die Loopback-.test-Site auf 8080 aus der Nginx-Lektion ist für die Ausstellung eines öffentlichen Zertifikats nicht geeignet. Bereiten Sie eine echte Website vor, deren DNS, Nginx server_name, Dokumentenstamm und Port-80-Antwort korrekt sind. Wenn ein AAAA-Eintrag existiert, muss auch die IPv6-Route funktionieren.

Geben Sie die echte Domain für die folgenden Abfragen ein. Installieren Sie das dnsutils-Paket von Ubuntu, falls dig fehlt. Überprüfen Sie DNS und HTTP von einem separaten Netzwerk aus und prüfen Sie gemeinsam Host-, Router- und Cloud-Regeln.

read -r -p "Domain you control: " domain
dig +short A "$domain"
dig +short AAAA "$domain"
curl -I "http://$domain/"

Schließen Sie zunächst die HTTP-Site in der realen Domain ab

Dieser Abschnitt richtet sich an einen separaten Ubuntu-Webserver, der über eine Domain, die Sie kontrollieren, unter einer öffentlichen Adresse erreichbar ist. Die nur-Host-VM, die im statischen IP-Labor verwendet wurde, ist nicht direkt über das Internet erreichbar. Ohne öffentliches Hosting/DNS sollten Sie die Ausstellung verschieben oder alternativ ein offizielles DNS-01-Plugin und eine geeignete sichere Ablage für Zugangsdaten auswählen.

Bereiten Sie Nginx/curl vor und weisen Sie den A-Eintrag der Domain auf die öffentliche IPv4-Adresse. Ein beworbener AAAA-Eintrag benötigt ebenfalls eine funktionierende IPv6-Route. Speichern Sie das vollständige Skript als ~/prepare-public-http.sh und führen Sie bash ~/prepare-public-http.sh IHRE_DOMAIN aus. Es akzeptiert gewöhnliche ASCII-Hostnamen; verwenden Sie für eine internationalisierte Domain verifiziertes Punycode. Es stoppt bei bereits vorhandenen Übungspfaden.

set -eu
if [ "$#" -ne 1 ]; then
    printf 'Usage: bash prepare-public-http.sh YOUR_DOMAIN\n' >&2; exit 2
fi
domain=$(printf '%s' "$1" | tr '[:upper:]' '[:lower:]')
if [[ ! "$domain" =~ ^([a-z0-9]([a-z0-9-]*[a-z0-9])?\.)+[a-z]([a-z0-9-]*[a-z0-9])?$ ]]; then
    printf 'Use a valid ASCII hostname you control.\n' >&2; exit 2
fi
case "$domain" in
    *.test|*.invalid|*.localhost|*.example|example.com|*.example.com)
        printf 'Use your real domain, not an example name.\n' >&2; exit 2 ;;
esac
site=/etc/nginx/sites-available/ubuntu-course-public
enabled=/etc/nginx/sites-enabled/ubuntu-course-public
root_dir=/srv/ubuntu-course-public
for path in "$site" "$enabled" "$root_dir"; do
    if sudo test -e "$path" || sudo test -L "$path"; then
        printf 'Existing lab path: %s; stop and inspect.\n' "$path" >&2; exit 1
    fi
done
backup_dir=$(sudo mktemp -d /root/nginx-before-public.XXXXXX)
sudo cp -a /etc/nginx "$backup_dir/"
sudo install -d -m 0755 "$root_dir"
printf 'public-http-lab\n' | sudo sh -c 'set -C; cat > "$1/index.html"' sh "$root_dir"
sudo chmod 0644 "$root_dir/index.html"
sudo sh -c 'set -C; cat > "$1"' sh "$site" <<EOF
server {
    listen 80;
    listen [::]:80;
    server_name $domain;
    root /srv/ubuntu-course-public;
    index index.html;
    location / {
        try_files \$uri \$uri/ =404;
    }
}
EOF
sudo ln -s "$site" "$enabled"
sudo nginx -t
sudo systemctl reload nginx
printf 'HTTP site prepared; backup: %s\n' "$backup_dir"

Wenn das IPv6-Abhören nicht verfügbar ist, passen Sie diese Abhörzeile an die tatsächliche Richtlinie an und geben Sie keine unbrauchbaren AAAA-Einträge bekannt. Fahren Sie erst fort, nachdem Erstellung, Validierung und Neuladen der Konfiguration erfolgreich waren. Im Falle eines Fehlers vergleichen Sie nur diese Änderung mit der Sicherung und bewahren andere Sites.

Auf dem neuen öffentlichen Server, wenn die Richtlinie öffentliches HTTP/HTTPS erlaubt und UFW bereits verwaltet wird, fügen Sie diese Zulassungen hinzu. SSH beibehalten und passende Pfade für den Provider-Firewall/Sicherheitsgruppe vorbereiten. Dies aktiviert UFW nicht. Die Zulassung nur des Lab-Clients .10 ist für die externe HTTP-01-Validierung nicht ausreichend.

sudo ufw allow 80/tcp && sudo ufw allow 443/tcp && sudo ufw status verbose

Die Domain-Variable des eigenständigen Skripts bleibt in der übergeordneten Shell nicht erhalten. Geben Sie den tatsächlichen Hostnamen in der aktuellen Bash-Sitzung erneut ein und überprüfen Sie public-http-lab auch von einer anderen Internetverbindung aus. Vergleichen Sie Hostname, Body und A/AAAA-Pfade, bevor Sie mit Certbot fortfahren.

read -r -p "Domain you control: " domain
dig +short A "$domain"
dig +short AAAA "$domain"
curl --fail --show-error "http://$domain/"

Wählen Sie einen Certbot-Installationsweg

Falls Certbot bereits existiert, prüfen Sie dessen Ursprung und Erneuerungsaufgabe, bevor Sie APT-, Snap- oder pip-Installationen kombinieren. Dieses Beispiel wählt den offiziellen Snap-Weg auf einem neuen dedizierten Server. Überprüfen Sie dessen Classic-Access-Anforderung und verwenden Sie den vollständigen Befehlsweg, um zu vermeiden, dass eine andere Installation aufgerufen wird.

sudo snap install --classic certbot
/snap/bin/certbot --version

Die offiziellen Nginx/Snap-Anweisungen von Certbot decken Installation, Ausstellung und Erneuerungstests ab.

Sichern und validieren vor der Ausstellung

(
set -eu
backup=$(sudo mktemp -d /root/nginx-before-tls.XXXXXX)
sudo cp -a /etc/nginx "$backup/"
sudo nginx -t
sudo /snap/bin/certbot --nginx -d "$domain"
)

Stellen Sie sicher, dass die Variable domain den echten Hostnamen in derselben Bash-Sitzung enthält, und führen Sie Certbot erst nach erfolgreicher Syntaxprüfung aus. Überprüfen Sie E-Mail, Bedingungen und Weiterleitungsoptionen. Die automatische Installation bearbeitet Nginx-Dateien, daher sollten Sie die Änderungen mit dem Backup vergleichen.

HTTP-01 benötigt eine Route, die vom externen Validator erreichbar ist. Für andere Umgebungen wählen Sie eine dokumentierte Alternative wie ein offizielles DNS-Plugin und schützen Sie DNS-Zugangsdaten mit minimalem Umfang. Untersuchen Sie DNS, Ports und Validierungsprotokolle, bevor Sie fehlgeschlagene Ausstellungsanforderungen wiederholen.

Überprüfen Sie externes HTTPS und das bereitgestellte Zertifikat

curl --fail --show-error "https://$domain/"
openssl s_client -connect "$domain:443" -servername "$domain" -verify_return_error -verify_hostname "$domain" </dev/null

Überprüfen Sie Hostname- und Kettenverifizierung sowie die erwartete Webantwort. Stellen Sie keinen Erfolg mit curl -k her. Eine lokale Zertifikatsdatei kann aktuell sein, während ein Proxy, Load Balancer oder ein anderer IPv6-Server ein älteres ausliefert; testen Sie den benutzerzugänglichen Pfad.

Testen Sie die Erneuerung und überwachen Sie das Ablaufdatum

sudo /snap/bin/certbot certificates
sudo /snap/bin/certbot renew --dry-run
systemctl list-timers --all | grep certbot

Ein Trockenlauf testet den aktuellen Validierungs-/Erneuerungsweg; er garantiert keinen zukünftigen planmäßigen Erfolg. Überprüfen Sie Timer und Protokolle und richten Sie Benachrichtigungen bei Fehlern und externem Ablauf ein. Lesen Sie das tatsächliche notAfter-Datum, anstatt eine feste Zertifikatslaufzeit anzunehmen.

Für ein Rollback nur diese Certbot/Nginx-Änderung überprüfen und die Zertifikate sowie Erneuerungseinstellungen anderer Domains beibehalten. Überprüfen Sie das aktualisierte bereitgestellte Zertifikat und die Service-Antwort nach der Erneuerung, um die Betriebsprüfung abzuschließen.