netcup DNS-API: Let's-Encrypt-Zertifikate per acme.sh ausstellen

Dies ist Teil 34 unserer netcup-Serie. Davor: Teil 33: SPF, DKIM, DMARC. Danach: Teil 35: Zusätzliche IPv4.

Ein Wildcard-Zertifikat für *.example.com lässt sich bei Let's Encrypt nur über die DNS-Challenge ausstellen. Dabei legt ein Programm kurz einen TXT-Eintrag in Ihrer Zone an. Bei netcup geht das über die API, und welchen Schlüssel Sie brauchen, hängt von der Domain ab. Die Wahl ist auch eine Sicherheitsfrage: Die Dokumentation nennt keine Beschränkung auf einzelne Domains, gehen Sie also davon aus, dass der Schlüssel alle DNS-Zonen Ihres Kontos ändern kann.

Diese Anleitung ist mit der netcup-Dokumentation und der Dokumentation von acme.sh abgeglichen (Stand 30.10.2026). Die Befehle wurden nicht gegen die netcup-API getestet.

Voraussetzungen

• Domain mit netcup-Nameservern
• Linux-Server mit curl, cron und openssl. acme.sh bricht die Installation ohne cron ab
• Root-Zugang, denn diese Anleitung führt acme.sh als root aus, damit Zertifikat und Webserver-Neuladen auch bei der Verlängerung funktionieren
• Zugang zum CCP

Schritt 1: Richtigen API-Typ bestimmen

Öffnen Sie im CCP unter Domains die Lupe neben der Domain und sehen Sie auf den Tab:

Verifizieren: Sie wissen, welcher Typ für Ihre Domain gilt. Bei gemischten Konten kann es beide geben.

Schritt 2: Zugang im CCP anlegen

Gehen Sie im CCP zu Stammdaten, API. Für die netcup-API klicken Sie unter API-Keys auf API-Key erstellen, geben eine Beschreibung ein, stimmen den Nutzungsbedingungen zu und bestätigen.

Für die Legacy-API erstellen Sie einen Legacy-API-Key und ein Legacy-API-Passwort. Das Passwort zeigt das CCP einmalig an, es gibt nur eines je Kundenkonto. Ein neues Passwort macht das alte ungültig, passen Sie dann alle Clients an.

Verifizieren: Der Schlüssel steht in der Liste, und das Passwort liegt in Ihrem Passwortmanager.

Schritt 3: acme.sh installieren

acme.sh ist ein Shell-Client mit eingebauter netcup-Anbindung. Er steht nicht in netcups Client-Liste, Clients Dritter laufen ohne Haftung und Support von netcup. Melden Sie sich als root an und installieren Sie ihn laut Projekt so:

sudo -i
apt-get install -y curl cron openssl
curl https://get.acme.sh | sh -s email=admin@example.com
exec bash
acme.sh --set-default-ca --server letsencrypt

Die Standard-CA von acme.sh ist nicht Let's Encrypt, deshalb die letzte Zeile.

Verifizieren: acme.sh --version gibt die Version aus.

Schritt 4: Zertifikat ausstellen

Setzen Sie die Zugangsdaten. acme.sh unterscheidet die APIs laut Dokumentation an der Länge des Schlüssels: 64 Zeichen für die neue API, 50 für die Legacy-API.

# netcup-API
read -rs NC_Apikey && export NC_Apikey

# nur Legacy-API zusätzlich
read -rs NC_Apipw && export NC_Apipw
export NC_CID="IHRE-KUNDENNUMMER"

acme.sh --issue --dns dns_netcup -d example.com -d "*.example.com"

read -rs liest den Wert ohne Anzeige, so landet er nicht in der Shell-History. Fügen Sie ihn ein und drücken Sie Enter. Nach dem ersten Lauf speichert acme.sh die Werte in ~/.acme.sh/account.conf und nutzt sie für Verlängerungen. Löschen Sie die Variablen danach mit unset NC_Apikey NC_Apipw NC_CID.

Verifizieren: Die Ausgabe nennt die Pfade von Zertifikat und Schlüssel, und acme.sh --list führt die Domain auf.

Schritt 5: Zertifikat einbinden

Nutzen Sie nicht die Dateien aus ~/.acme.sh direkt, sondern lassen Sie sie kopieren. Dann werden sie bei einer Verlängerung neu geschrieben:

mkdir -p /etc/ssl/example.com
acme.sh --install-cert -d example.com \
  --key-file /etc/ssl/example.com/key.pem \
  --fullchain-file /etc/ssl/example.com/fullchain.pem \
  --reloadcmd "systemctl reload nginx"

Führen Sie das als root aus, wie seit Schritt 3. Sonst scheitert das Schreiben nach /etc/ssl oder das Neuladen, und nginx läuft bei einer Verlängerung mit dem alten Zertifikat weiter, bis es abläuft.

In der nginx-Konfiguration verweisen Sie auf die kopierten Dateien:

server {
    listen 443 ssl;
    server_name example.com *.example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/key.pem;
}

Prüfen Sie die Konfiguration mit nginx -t und laden Sie sie mit systemctl reload nginx.

Verifizieren: openssl x509 -in /etc/ssl/example.com/fullchain.pem -noout -dates -ext subjectAltName zeigt Laufzeit und beide Namen.

Schritt 6: Verlängerung prüfen

Die Installation legt einen Cron-Job an. Prüfen Sie, dass er besteht und welches Datum acme.sh für die Verlängerung plant:

crontab -l | grep acme.sh
acme.sh --list
acme.sh --cron

Der letzte Befehl läuft wie der Cron-Job und verlängert nur fällige Zertifikate. Sehen Sie sich an einem Termin nach der ersten Verlängerung an, ob das neue Zertifikat wirklich ausgeliefert wird:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates

Verifizieren: Der Cron-Job ist vorhanden, und acme.sh --cron endet ohne Fehler.

Schritt 7: Zugang schützen

• Legen Sie je Server einen eigenen API-Key an. Das begrenzt nicht die Rechte, aber Sie können einen einzelnen Zugang sperren. Bei der Legacy-API teilen sich alle Keys ein Passwort, ein neues betrifft also alle Clients.
• Für die Legacy-API beschreibt netcup unter Domains, API Log ein Protokoll, der Knopf erscheint bei Kunden ohne Reseller-Vertrag erst nach der ersten API-Aktion. Für die netcup-API nennt die Dokumentation das nicht.
• Löschen Sie nicht mehr genutzte Schlüssel über das Mülleimer-Symbol.

Verifizieren: Jeder Schlüssel hat eine eindeutige Beschreibung.

Troubleshooting

Häufige Fragen

Brauche ich das ohne Wildcard?

Nein. Für einzelne Namen reicht die HTTP-Prüfung, siehe unsere Anleitung zu certbot oder Teil 17.

Gibt es Alternativen zu acme.sh?

Ja. netcup nennt in seiner Liste von Clients unter anderem ein Plugin für certbot. Prüfen Sie vor dem Einsatz, ob das Projekt gepflegt wird.

Fazit

Bestimmen Sie den API-Typ am Tab der Domain, nehmen Sie je Server einen eigenen Schlüssel, und behandeln Sie ihn wie ein Passwort. Prüfen Sie nach der ersten Verlängerung, ob der Webserver das neue Zertifikat wirklich ausliefert.

Weiterführende Anleitungen und Quellen

• Teil 7: DNS-Records
• Teil 15: REST-API
• netcup Helpcenter: netcup-API
• netcup Helpcenter: Legacy-API
• acme.sh: netcup DNS API