Letsencrypt DNS Verification RFC2136 - Versionsgeschichte

Thomas.will: /* 2. Zugang testen (noch ohne Certbot) */

2026-10-24T12:20:21Z

2. Zugang testen (noch ohne Certbot)

← Nächstältere Version		Version vom 24. Oktober 2026, 12:20 Uhr
Zeile 78:		Zeile 78:
	server ns1.example.com		server ns1.example.com
	zone example.com		zone example.com
	update add _acme-challenge~~.wiki~~.example.com. 60 TXT "test"		update add _acme-challenge.example.com. 60 TXT "test"
	send		send
	quit		quit
	*dig +short TXT _acme-challenge~~.wiki~~.example.com @ns1.example.com		*dig +short TXT _acme-challenge.example.com @ns1.example.com
	"test"		"test"
	;Aufräumen		;Aufräumen
Zeile 87:		Zeile 87:
	server ns1.example.com		server ns1.example.com
	zone example.com		zone example.com
	update delete _acme-challenge~~.wiki~~.example.com. TXT		update delete _acme-challenge.example.com. TXT
	send		send
	quit		quit

Thomas.will: Nur noch ein Beispiel: Domain+Wildcard in einem Cert, Einzelhost-Fall raus

2026-10-22T18:07:19Z

Nur noch ein Beispiel: Domain+Wildcard in einem Cert, Einzelhost-Fall raus

← Nächstältere Version		Version vom 22. Oktober 2026, 18:07 Uhr
Zeile 113:		Zeile 113:

	==Zertifikat ausstellen==		==Zertifikat ausstellen==
	*Pro Zweck ein eigenes Zertifikat: einen eigenständigen vHost (z. B. <code>wiki.example.com</code>) und die Apex-Domain (<code>example.com</code>, ggf. mit Wildcard) '''nicht''' in einen gemeinsamen <code>--cert-name</code> mischen, außer beide werden wirklich vom selben Webserver-vHost mit derselben Konfiguration bedient.		certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini --dns-rfc2136-propagation-seconds 10 --cert-name example.com -d example.com -d '.example.com' --agree-tos -m admin@example.com
	~~;Einzelner Host~~
	*certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini --dns-rfc2136-propagation-seconds 10 --cert-name ~~wiki~~.example.com -d ~~wiki~~.example.com --agree-tos -m admin@example.com
	;Ergebnis		;Ergebnis
	/etc/letsencrypt/live/~~wiki.~~example.com/fullchain.pem		/etc/letsencrypt/live/example.com/fullchain.pem
	/etc/letsencrypt/live/~~wiki.~~example.com/privkey.pem		/etc/letsencrypt/live/example.com/privkey.pem
	~~;Wildcard~~
	certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini --dns-rfc2136-propagation-seconds 10 --cert-name example.com -d example.com -d '.example.com'
	*Das Sternchen '''unbedingt in Anführungszeichen''', sonst expandiert ihn die Shell gegen Dateinamen im aktuellen Verzeichnis, bevor certbot ihn überhaupt sieht.		*Das Sternchen '''unbedingt in Anführungszeichen''', sonst expandiert ihn die Shell gegen Dateinamen im aktuellen Verzeichnis, bevor certbot ihn überhaupt sieht.
	Existiert das Zertifikat schon ohne Wildcard, reicht ein erneutes <code>certbot certonly</code> mit demselben <code>--cert-name</code> und der zusätzlichen SAN <code>-d '.example.com'</code> — es wird dann um den Wildcard-Eintrag erweitert, nicht neu angelegt.		Existiert das Zertifikat schon ohne Wildcard, reicht ein erneutes <code>certbot certonly</code> mit demselben <code>--cert-name</code> und der zusätzlichen SAN <code>-d '.example.com'</code> — es wird dann um den Wildcard-Eintrag erweitert, nicht neu angelegt.
Zeile 127:		Zeile 123:
	==Bestehendes Zertifikat (HTTP) auf DNS umstellen==		==Bestehendes Zertifikat (HTTP) auf DNS umstellen==
	Ab Certbot 4.0 (Debian 13) ohne neu auszustellen:		Ab Certbot 4.0 (Debian 13) ohne neu auszustellen:
	*certbot reconfigure --cert-name ~~wiki.~~example.com --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini --dns-rfc2136-propagation-seconds 10		*certbot reconfigure --cert-name example.com --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini --dns-rfc2136-propagation-seconds 10
	*grep -E "authenticator\|dns_rfc2136" /etc/letsencrypt/renewal/~~wiki.~~example.com.conf		*grep -E "authenticator\|dns_rfc2136" /etc/letsencrypt/renewal/example.com.conf
	authenticator = dns-rfc2136		authenticator = dns-rfc2136
	Certbot macht dabei einen Testlauf. Danach erneuert sich das Zertifikat mit der DNS-Challenge.		Certbot macht dabei einen Testlauf. Danach erneuert sich das Zertifikat mit der DNS-Challenge.

Thomas.will: Platzhalter-Domain: example.org durchgehend durch example.com ersetzt

2026-10-22T18:05:27Z

Platzhalter-Domain: example.org durchgehend durch example.com ersetzt

← Nächstältere Version		Version vom 22. Oktober 2026, 18:05 Uhr
Zeile 17:		Zeile 17:
	=Wann braucht man das=		=Wann braucht man das=
	*Port 80 ist nicht erreichbar oder wird gefiltert (Firewall, Sperrlisten gegen Bots).		*Port 80 ist nicht erreichbar oder wird gefiltert (Firewall, Sperrlisten gegen Bots).
	Wildcard-Zertifikate (<code>.example.~~org~~</code>), das geht nur per DNS-Challenge.		Wildcard-Zertifikate (<code>.example.com</code>), das geht nur per DNS-Challenge.
	*Das Zertifikat soll '''vor''' einem DNS-Umzug fertig sein, der Name zeigt noch auf den alten Server.		*Das Zertifikat soll '''vor''' einem DNS-Umzug fertig sein, der Name zeigt noch auf den alten Server.
	*Die HTTP-Prüfung macht Probleme (Weiterleitungen, mehrere Server hinter einem Namen).		*Die HTTP-Prüfung macht Probleme (Weiterleitungen, mehrere Server hinter einem Namen).
Zeile 45:		Zeile 45:
	include "/etc/bind/acme-update.key";		include "/etc/bind/acme-update.key";

	zone "example.~~org~~" {		zone "example.com" {
	type master;		type master;
	file "example.~~org~~";		file "example.com";
	update-policy {		update-policy {
	grant acme-update name _acme-challenge.example.~~org~~. TXT;		grant acme-update name _acme-challenge.example.com. TXT;
	};		};
	};		};
	</syntaxhighlight>		</syntaxhighlight>
	Wildcard und Hauptname (<code>example.~~org~~</code> und <code>.example.~~org~~</code>) teilen sich '''denselben''' Namen <code>_acme-challenge.example.~~org~~</code> — eine einzige Freigabe reicht für beide, dort stehen dann zwei TXT-Werte gleichzeitig.		Wildcard und Hauptname (<code>example.com</code> und <code>.example.com</code>) teilen sich '''denselben''' Namen <code>_acme-challenge.example.com</code> — eine einzige Freigabe reicht für beide, dort stehen dann zwei TXT-Werte gleichzeitig.
	*<code>file</code> ohne Pfad und ohne Endung, wie bei den anderen Zonen auch: BIND sucht sie im konfigurierten Zonenverzeichnis.		*<code>file</code> ohne Pfad und ohne Endung, wie bei den anderen Zonen auch: BIND sucht sie im konfigurierten Zonenverzeichnis.
	*Zusätzliche, eigenständige Namen außerhalb der Wildcard (z. B. ein eigener vHost wie <code>wiki.example.~~org~~</code>, der '''nicht''' im Wildcard-Zertifikat steckt) brauchen einen eigenen Grant: <code>grant acme-update name _acme-challenge.wiki.example.~~org~~. TXT;</code> — nur nötig, wenn dafür wirklich ein eigenes Zertifikat per DNS-Challenge ausgestellt wird.		*Zusätzliche, eigenständige Namen außerhalb der Wildcard (z. B. ein eigener vHost wie <code>wiki.example.com</code>, der '''nicht''' im Wildcard-Zertifikat steckt) brauchen einen eigenen Grant: <code>grant acme-update name _acme-challenge.wiki.example.com. TXT;</code> — nur nötig, wenn dafür wirklich ein eigenes Zertifikat per DNS-Challenge ausgestellt wird.
	*Der Schlüssel darf '''nur TXT''' an diese Namen ändern, sonst nichts in der Zone.		*Der Schlüssel darf '''nur TXT''' an diese Namen ändern, sonst nichts in der Zone.
	*Die Kurzform <code>grant acme-update zonesub TXT;</code> erlaubt TXT überall in der Zone. Das ist bequemer, aber weniger streng.		*Die Kurzform <code>grant acme-update zonesub TXT;</code> erlaubt TXT überall in der Zone. Das ist bequemer, aber weniger streng.
Zeile 62:		Zeile 62:
	*Die Zonendatei muss für den BIND-Benutzer beschreibbar sein (unter Debian <code>/var/cache/bind/</code>, Besitzer <code>bind:bind</code> — <code>/etc/bind/</code> und <code>/var/lib/bind/</code> gehören root und sind für den BIND-Prozess nicht beschreibbar).		*Die Zonendatei muss für den BIND-Benutzer beschreibbar sein (unter Debian <code>/var/cache/bind/</code>, Besitzer <code>bind:bind</code> — <code>/etc/bind/</code> und <code>/var/lib/bind/</code> gehören root und sind für den BIND-Prozess nicht beschreibbar).
	*Von Hand ändern geht nur noch mit Einfrieren, sonst gehen Änderungen verloren:		*Von Hand ändern geht nur noch mit Einfrieren, sonst gehen Änderungen verloren:
	**rndc freeze example.~~org~~		**rndc freeze example.com
	**Zonendatei bearbeiten		**Zonendatei bearbeiten
	**rndc thaw example.~~org~~		**rndc thaw example.com
	*Neben der Zonendatei liegt ein Journal (<code>.jnl</code>), das gehört zur Zone und darf nicht gelöscht werden.		*Neben der Zonendatei liegt ein Journal (<code>.jnl</code>), das gehört zur Zone und darf nicht gelöscht werden.

Zeile 76:		Zeile 76:
	*scp /etc/bind/acme-update.key webserver:/root/acme-update.key		*scp /etc/bind/acme-update.key webserver:/root/acme-update.key
	*nsupdate -k /root/acme-update.key		*nsupdate -k /root/acme-update.key
	server ns1.example.~~org~~		server ns1.example.com
	zone example.~~org~~		zone example.com
	update add _acme-challenge.wiki.example.~~org~~. 60 TXT "test"		update add _acme-challenge.wiki.example.com. 60 TXT "test"
	send		send
	quit		quit
	*dig +short TXT _acme-challenge.wiki.example.~~org~~ @ns1.example.~~org~~		*dig +short TXT _acme-challenge.wiki.example.com @ns1.example.com
	"test"		"test"
	;Aufräumen		;Aufräumen
	*nsupdate -k /root/acme-update.key		*nsupdate -k /root/acme-update.key
	server ns1.example.~~org~~		server ns1.example.com
	zone example.~~org~~		zone example.com
	update delete _acme-challenge.wiki.example.~~org~~. TXT		update delete _acme-challenge.wiki.example.com. TXT
	send		send
	quit		quit
Zeile 113:		Zeile 113:

	==Zertifikat ausstellen==		==Zertifikat ausstellen==
	*Pro Zweck ein eigenes Zertifikat: einen eigenständigen vHost (z. B. <code>wiki.example.~~org~~</code>) und die Apex-Domain (<code>example.~~org~~</code>, ggf. mit Wildcard) '''nicht''' in einen gemeinsamen <code>--cert-name</code> mischen, außer beide werden wirklich vom selben Webserver-vHost mit derselben Konfiguration bedient.		*Pro Zweck ein eigenes Zertifikat: einen eigenständigen vHost (z. B. <code>wiki.example.com</code>) und die Apex-Domain (<code>example.com</code>, ggf. mit Wildcard) '''nicht''' in einen gemeinsamen <code>--cert-name</code> mischen, außer beide werden wirklich vom selben Webserver-vHost mit derselben Konfiguration bedient.
	;Einzelner Host		;Einzelner Host
	*certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini --dns-rfc2136-propagation-seconds 10 --cert-name wiki.example.~~org~~ -d wiki.example.~~org~~ --agree-tos -m admin@example.~~org~~		*certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini --dns-rfc2136-propagation-seconds 10 --cert-name wiki.example.com -d wiki.example.com --agree-tos -m admin@example.com
	;Ergebnis		;Ergebnis
	/etc/letsencrypt/live/wiki.example.~~org~~/fullchain.pem		/etc/letsencrypt/live/wiki.example.com/fullchain.pem
	/etc/letsencrypt/live/wiki.example.~~org~~/privkey.pem		/etc/letsencrypt/live/wiki.example.com/privkey.pem
	;Wildcard		;Wildcard
	certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini --dns-rfc2136-propagation-seconds 10 --cert-name example.~~org~~ -d example.~~org~~ -d '.example.~~org~~'		certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini --dns-rfc2136-propagation-seconds 10 --cert-name example.com -d example.com -d '.example.com'
	*Das Sternchen '''unbedingt in Anführungszeichen''', sonst expandiert ihn die Shell gegen Dateinamen im aktuellen Verzeichnis, bevor certbot ihn überhaupt sieht.		*Das Sternchen '''unbedingt in Anführungszeichen''', sonst expandiert ihn die Shell gegen Dateinamen im aktuellen Verzeichnis, bevor certbot ihn überhaupt sieht.
	Existiert das Zertifikat schon ohne Wildcard, reicht ein erneutes <code>certbot certonly</code> mit demselben <code>--cert-name</code> und der zusätzlichen SAN <code>-d '.example.~~org~~'</code> — es wird dann um den Wildcard-Eintrag erweitert, nicht neu angelegt.		Existiert das Zertifikat schon ohne Wildcard, reicht ein erneutes <code>certbot certonly</code> mit demselben <code>--cert-name</code> und der zusätzlichen SAN <code>-d '.example.com'</code> — es wird dann um den Wildcard-Eintrag erweitert, nicht neu angelegt.
	*Ohne Anführungszeichen vergessen und stattdessen zweimal denselben Namen angegeben (<code>-d example.~~org~~ -d example.~~org~~</code>) stellt certbot klaglos ein Zertifikat '''ohne''' Wildcard aus — kein Fehler, nur fehlt dann die zweite SAN.		*Ohne Anführungszeichen vergessen und stattdessen zweimal denselben Namen angegeben (<code>-d example.com -d example.com</code>) stellt certbot klaglos ein Zertifikat '''ohne''' Wildcard aus — kein Fehler, nur fehlt dann die zweite SAN.

	==Bestehendes Zertifikat (HTTP) auf DNS umstellen==		==Bestehendes Zertifikat (HTTP) auf DNS umstellen==
	Ab Certbot 4.0 (Debian 13) ohne neu auszustellen:		Ab Certbot 4.0 (Debian 13) ohne neu auszustellen:
	*certbot reconfigure --cert-name wiki.example.~~org~~ --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini --dns-rfc2136-propagation-seconds 10		*certbot reconfigure --cert-name wiki.example.com --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini --dns-rfc2136-propagation-seconds 10
	*grep -E "authenticator\|dns_rfc2136" /etc/letsencrypt/renewal/wiki.example.~~org~~.conf		*grep -E "authenticator\|dns_rfc2136" /etc/letsencrypt/renewal/wiki.example.com.conf
	authenticator = dns-rfc2136		authenticator = dns-rfc2136
	Certbot macht dabei einen Testlauf. Danach erneuert sich das Zertifikat mit der DNS-Challenge.		Certbot macht dabei einen Testlauf. Danach erneuert sich das Zertifikat mit der DNS-Challenge.
Zeile 165:		Zeile 165:
	*tail -f /var/log/letsencrypt/letsencrypt.log		*tail -f /var/log/letsencrypt/letsencrypt.log
	;Was Let's Encrypt sieht		;Was Let's Encrypt sieht
	*dig +short TXT _acme-challenge.wiki.example.~~org~~ @ns1.example.~~org~~		*dig +short TXT _acme-challenge.wiki.example.com @ns1.example.com
	*Die Abfrage geht an die '''autoritativen''' Server der Zone, nicht an deinen Resolver.		*Die Abfrage geht an die '''autoritativen''' Server der Zone, nicht an deinen Resolver.

Thomas.will: Beispiel entschlackt: vHost und Apex-Domain nicht mehr in einem Cert mischen

2026-10-22T18:05:10Z

Beispiel entschlackt: vHost und Apex-Domain nicht mehr in einem Cert mischen

← Nächstältere Version		Version vom 22. Oktober 2026, 18:05 Uhr
Zeile 113:		Zeile 113:

	==Zertifikat ausstellen==		==Zertifikat ausstellen==
	*certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini --dns-rfc2136-propagation-seconds 10 --cert-name wiki.example.org -d wiki.~~example.org -d~~ example.org --agree-tos -m admin@example.org		*Pro Zweck ein eigenes Zertifikat: einen eigenständigen vHost (z. B. <code>wiki.example.org</code>) und die Apex-Domain (<code>example.org</code>, ggf. mit Wildcard) '''nicht''' in einen gemeinsamen <code>--cert-name</code> mischen, außer beide werden wirklich vom selben Webserver-vHost mit derselben Konfiguration bedient.
			;Einzelner Host
			*certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini --dns-rfc2136-propagation-seconds 10 --cert-name wiki.example.org -d wiki.example.org --agree-tos -m admin@example.org
	;Ergebnis		;Ergebnis
	/etc/letsencrypt/live/wiki.example.org/fullchain.pem		/etc/letsencrypt/live/wiki.example.org/fullchain.pem

Thomas.will: Hinweis: Wildcard-Stern quoten, sonst keine SAN

2026-10-22T17:39:38Z

Hinweis: Wildcard-Stern quoten, sonst keine SAN

← Nächstältere Version		Version vom 22. Oktober 2026, 17:39 Uhr
Zeile 119:		Zeile 119:
	;Wildcard		;Wildcard
	certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini --dns-rfc2136-propagation-seconds 10 --cert-name example.org -d example.org -d '.example.org'		certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini --dns-rfc2136-propagation-seconds 10 --cert-name example.org -d example.org -d '.example.org'
			*Das Sternchen '''unbedingt in Anführungszeichen''', sonst expandiert ihn die Shell gegen Dateinamen im aktuellen Verzeichnis, bevor certbot ihn überhaupt sieht.
			Existiert das Zertifikat schon ohne Wildcard, reicht ein erneutes <code>certbot certonly</code> mit demselben <code>--cert-name</code> und der zusätzlichen SAN <code>-d '.example.org'</code> — es wird dann um den Wildcard-Eintrag erweitert, nicht neu angelegt.
			*Ohne Anführungszeichen vergessen und stattdessen zweimal denselben Namen angegeben (<code>-d example.org -d example.org</code>) stellt certbot klaglos ein Zertifikat '''ohne''' Wildcard aus — kein Fehler, nur fehlt dann die zweite SAN.

	==Bestehendes Zertifikat (HTTP) auf DNS umstellen==		==Bestehendes Zertifikat (HTTP) auf DNS umstellen==

Thomas.will: Beispiel praezisiert: eigener vHost ausserhalb des Wildcards

2026-10-22T17:36:56Z

Beispiel praezisiert: eigener vHost ausserhalb des Wildcards

← Nächstältere Version		Version vom 22. Oktober 2026, 17:36 Uhr
Zeile 55:		Zeile 55:
	Wildcard und Hauptname (<code>example.org</code> und <code>.example.org</code>) teilen sich '''denselben''' Namen <code>_acme-challenge.example.org</code> — eine einzige Freigabe reicht für beide, dort stehen dann zwei TXT-Werte gleichzeitig.		Wildcard und Hauptname (<code>example.org</code> und <code>.example.org</code>) teilen sich '''denselben''' Namen <code>_acme-challenge.example.org</code> — eine einzige Freigabe reicht für beide, dort stehen dann zwei TXT-Werte gleichzeitig.
	*<code>file</code> ohne Pfad und ohne Endung, wie bei den anderen Zonen auch: BIND sucht sie im konfigurierten Zonenverzeichnis.		*<code>file</code> ohne Pfad und ohne Endung, wie bei den anderen Zonen auch: BIND sucht sie im konfigurierten Zonenverzeichnis.
	*Zusätzliche, eigenständige Namen außerhalb der Wildcard (z. B. ein ~~zweistufiges~~ <code>~~a.b~~.example.org</code>) brauchen einen eigenen Grant: <code>grant acme-update name _acme-challenge.~~a.b~~.example.org. TXT;</code>		*Zusätzliche, eigenständige Namen außerhalb der Wildcard (z. B. ein eigener vHost wie <code>wiki.example.org</code>, der '''nicht''' im Wildcard-Zertifikat steckt) brauchen einen eigenen Grant: <code>grant acme-update name _acme-challenge.wiki.example.org. TXT;</code> — nur nötig, wenn dafür wirklich ein eigenes Zertifikat per DNS-Challenge ausgestellt wird.
	*Der Schlüssel darf '''nur TXT''' an diese Namen ändern, sonst nichts in der Zone.		*Der Schlüssel darf '''nur TXT''' an diese Namen ändern, sonst nichts in der Zone.
	*Die Kurzform <code>grant acme-update zonesub TXT;</code> erlaubt TXT überall in der Zone. Das ist bequemer, aber weniger streng.		*Die Kurzform <code>grant acme-update zonesub TXT;</code> erlaubt TXT überall in der Zone. Das ist bequemer, aber weniger streng.

Thomas.will: Testabschnitt korrigiert: Webserver hat kein /etc/bind, Schlüsseldatei dorthin kopiert z.B. nach /root

2026-10-22T15:27:35Z

Testabschnitt korrigiert: Webserver hat kein /etc/bind, Schlüsseldatei dorthin kopiert z.B. nach /root

← Nächstältere Version		Version vom 22. Oktober 2026, 15:27 Uhr
Zeile 73:		Zeile 73:
	=2. Zugang testen (noch ohne Certbot)=		=2. Zugang testen (noch ohne Certbot)=
	;Vom Webserver aus, mit kopierter Schlüsseldatei		;Vom Webserver aus, mit kopierter Schlüsseldatei
	*nsupdate -k /~~etc/bind~~/acme-update.key		Auf dem Webserver ist kein BIND installiert, <code>/etc/bind/</code> gibt es dort also nicht. Die Schlüsseldatei landet einfach irgendwo, z. B. unter <code>/root/</code>:
			*scp /etc/bind/acme-update.key webserver:/root/acme-update.key
			*nsupdate -k /root/acme-update.key
	server ns1.example.org		server ns1.example.org
	zone example.org		zone example.org
Zeile 82:		Zeile 84:
	"test"		"test"
	;Aufräumen		;Aufräumen
	*nsupdate -k /~~etc/bind~~/acme-update.key		*nsupdate -k /root/acme-update.key
	server ns1.example.org		server ns1.example.org
	zone example.org		zone example.org

Thomas.will: Zonenverzeichnis unter Debian korrigiert: /var/cache/bind statt /var/lib/bind

2026-10-22T15:25:36Z

Zonenverzeichnis unter Debian korrigiert: /var/cache/bind statt /var/lib/bind

← Nächstältere Version		Version vom 22. Oktober 2026, 15:25 Uhr
Zeile 60:		Zeile 60:

	;Wichtig: die Zone ist jetzt dynamisch		;Wichtig: die Zone ist jetzt dynamisch
	*Die Zonendatei muss für den BIND-Benutzer beschreibbar sein (unter Debian <code>/var/~~lib~~/bind/</code>, ~~nicht~~ <code>/etc/bind/</code>).		*Die Zonendatei muss für den BIND-Benutzer beschreibbar sein (unter Debian <code>/var/cache/bind/</code>, Besitzer <code>bind:bind</code> — <code>/etc/bind/</code> und <code>/var/lib/bind/</code> gehören root und sind für den BIND-Prozess nicht beschreibbar).
	*Von Hand ändern geht nur noch mit Einfrieren, sonst gehen Änderungen verloren:		*Von Hand ändern geht nur noch mit Einfrieren, sonst gehen Änderungen verloren:
	**rndc freeze example.org		**rndc freeze example.org

Thomas.will: Beispiel vereinfacht: ein Grant für Wildcard+Hauptname, file ohne Pfad/Endung

2026-10-22T15:21:31Z

Beispiel vereinfacht: ein Grant für Wildcard+Hauptname, file ohne Pfad/Endung

← Nächstältere Version		Version vom 22. Oktober 2026, 15:21 Uhr
Zeile 47:		Zeile 47:
	zone "example.org" {		zone "example.org" {
	type master;		type master;
	file "~~/var/lib/bind/db.~~example.org";		file "example.org";
	update-policy {		update-policy {
	grant acme-update name _acme-challenge~~.example.org. TXT;~~		grant acme-update name _acme-challenge.example.org. TXT;
	~~grant acme-update name _acme-challenge.www.example.org. TXT;~~
	~~grant acme-update name _acme-challenge.wiki~~.example.org. TXT;
	};		};
	};		};
	</syntaxhighlight>		</syntaxhighlight>
	*~~Pro Zertifikatsname gibt es '''genau einen eigenen'''~~ <code>~~_acme-challenge~~</code>~~-Namen: Für~~ <code>~~wiki~~.example.org</code> ~~ist es~~ <code>_acme-challenge~~.wiki~~.example.org</code>, ~~für <code>www~~.~~example.org~~</code> ~~entsprechend <code>_acme-challenge.www.example.org~~</code>.		Wildcard und Hauptname (<code>example.org</code> und <code>.example.org</code>) teilen sich '''denselben''' Namen <code>_acme-challenge.example.org</code> — eine einzige Freigabe reicht für beide, dort stehen dann zwei TXT-Werte gleichzeitig.
	Wildcard ~~und Hauptname~~ (<code>~~example~~.org</code> und <code>.example.org</code>) ~~teilen sich '''denselben''' Namen~~ <code>_acme-challenge.example.org</code>~~, dort stehen dann zwei TXT-Werte gleichzeitig.~~		*<code>file</code> ohne Pfad und ohne Endung, wie bei den anderen Zonen auch: BIND sucht sie im konfigurierten Zonenverzeichnis.
	*Der Schlüssel darf '''nur TXT''' an ~~diesen~~ Namen ändern, sonst nichts in der Zone.		*Zusätzliche, eigenständige Namen außerhalb der Wildcard (z. B. ein zweistufiges <code>a.b.example.org</code>) brauchen einen eigenen Grant: <code>grant acme-update name _acme-challenge.a.b.example.org. TXT;</code>
			*Der Schlüssel darf '''nur TXT''' an diese Namen ändern, sonst nichts in der Zone.
	*Die Kurzform <code>grant acme-update zonesub TXT;</code> erlaubt TXT überall in der Zone. Das ist bequemer, aber weniger streng.		*Die Kurzform <code>grant acme-update zonesub TXT;</code> erlaubt TXT überall in der Zone. Das ist bequemer, aber weniger streng.

Thomas.will: Neue Seite: DNS-Challenge mit dem Certbot-Plugin dns-rfc2136 (eigener BIND, TSIG, automatische Erneuerung)

2026-10-22T05:08:15Z

Neue Seite: DNS-Challenge mit dem Certbot-Plugin dns-rfc2136 (eigener BIND, TSIG, automatische Erneuerung)

Neue Seite

=Prinzip=
*Certbot hat ein eingebautes Plugin, das den TXT-Eintrag für die DNS-Challenge '''selbst per RFC 2136 (dynamisches DNS-Update)''' im eigenen BIND setzt und danach wieder löscht.
*Das ist der '''neue Weg''' gegenüber dem alten mit Hook-Skript (siehe [[Letsencrypt DNS Verification]]):
{| class="wikitable"
! !! Alter Weg !! Neuer Weg (Plugin)
|-
| Skript || eigenes <code>certbot-dns-validation.sh</code> || keins, das Plugin macht das
|-
| Schlüssel || steht im Skript || eigene Datei, nur root lesbar
|-
| Erneuerung || langer <code>certbot renew …</code>-Aufruf mit Hook || läuft automatisch über <code>certbot.timer</code>
|-
| Rechte im BIND || meist ganze Zone || nur TXT an den <code>_acme-challenge</code>-Namen
|}
*Voraussetzung: ein '''eigener BIND''', in dem du Zonen dynamisch ändern darfst.

=Wann braucht man das=
*Port 80 ist nicht erreichbar oder wird gefiltert (Firewall, Sperrlisten gegen Bots).
*Wildcard-Zertifikate (<code>*.example.org</code>), das geht nur per DNS-Challenge.
*Das Zertifikat soll '''vor''' einem DNS-Umzug fertig sein, der Name zeigt noch auf den alten Server.
*Die HTTP-Prüfung macht Probleme (Weiterleitungen, mehrere Server hinter einem Namen).

=Überblick=
Certbot (Webserver) --nsupdate (TSIG)--> BIND <--TXT-Abfrage-- Let's Encrypt
*Certbot setzt den TXT-Eintrag <code>_acme-challenge.NAME</code> im BIND.
*Let's Encrypt fragt die '''autoritativen''' Nameserver ab und prüft den Wert.
*Certbot löscht den Eintrag wieder.

=1. BIND vorbereiten=
==Schlüssel erzeugen==
;Auf dem Nameserver
*tsig-keygen -a hmac-sha256 acme-update > /etc/bind/acme-update.key
*chown root:bind /etc/bind/acme-update.key
*chmod 640 /etc/bind/acme-update.key
*cat /etc/bind/acme-update.key
key "acme-update" {
algorithm hmac-sha256;
secret "BASE64-GEHEIMNIS==";
};
Der Name des Schlüssels (hier <code>acme-update</code>) ist die Identität im BIND. Das Geheimnis wird gleich für Certbot gebraucht und '''nirgends sonst abgelegt'''.

==Schlüssel einbinden und Zone freigeben==
;Datei named.conf.local
<syntaxhighlight lang="text">
include "/etc/bind/acme-update.key";

zone "example.org" {
type master;
file "/var/lib/bind/db.example.org";
update-policy {
grant acme-update name _acme-challenge.example.org. TXT;
grant acme-update name _acme-challenge.www.example.org. TXT;
grant acme-update name _acme-challenge.wiki.example.org. TXT;
};
};
</syntaxhighlight>
*Pro Zertifikatsname gibt es '''genau einen eigenen''' <code>_acme-challenge</code>-Namen: Für <code>wiki.example.org</code> ist es <code>_acme-challenge.wiki.example.org</code>, für <code>www.example.org</code> entsprechend <code>_acme-challenge.www.example.org</code>.
*Wildcard und Hauptname (<code>example.org</code> und <code>*.example.org</code>) teilen sich '''denselben''' Namen <code>_acme-challenge.example.org</code>, dort stehen dann zwei TXT-Werte gleichzeitig.
*Der Schlüssel darf '''nur TXT''' an diesen Namen ändern, sonst nichts in der Zone.
*Die Kurzform <code>grant acme-update zonesub TXT;</code> erlaubt TXT überall in der Zone. Das ist bequemer, aber weniger streng.

;Wichtig: die Zone ist jetzt dynamisch
*Die Zonendatei muss für den BIND-Benutzer beschreibbar sein (unter Debian <code>/var/lib/bind/</code>, nicht <code>/etc/bind/</code>).
*Von Hand ändern geht nur noch mit Einfrieren, sonst gehen Änderungen verloren:
**rndc freeze example.org
**Zonendatei bearbeiten
**rndc thaw example.org
*Neben der Zonendatei liegt ein Journal (<code>.jnl</code>), das gehört zur Zone und darf nicht gelöscht werden.

;Konfiguration laden
*named-checkconf
*rndc reconfig

=2. Zugang testen (noch ohne Certbot)=
;Vom Webserver aus, mit kopierter Schlüsseldatei
*nsupdate -k /etc/bind/acme-update.key
server ns1.example.org
zone example.org
update add _acme-challenge.wiki.example.org. 60 TXT "test"
send
quit
*dig +short TXT _acme-challenge.wiki.example.org @ns1.example.org
"test"
;Aufräumen
*nsupdate -k /etc/bind/acme-update.key
server ns1.example.org
zone example.org
update delete _acme-challenge.wiki.example.org. TXT
send
quit
Klappt das, ist der BIND-Teil fertig. Meldet er <code>REFUSED</code>, siehe [[#Fehlersuche|Fehlersuche]].

=3. Certbot einrichten=
==Plugin installieren==
*apt install certbot python3-certbot-dns-rfc2136
*certbot --version

==Zugangsdatei==
*install -m 600 /dev/null /etc/letsencrypt/rfc2136.ini
*vim /etc/letsencrypt/rfc2136.ini
<syntaxhighlight lang="ini">
dns_rfc2136_server = IP-DES-NAMENSERVERS
dns_rfc2136_port = 53
dns_rfc2136_name = acme-update.
dns_rfc2136_secret = BASE64-GEHEIMNIS==
dns_rfc2136_algorithm = HMAC-SHA256
</syntaxhighlight>
*<code>dns_rfc2136_server</code> ist die Adresse des Nameservers, bei dem die Zone '''dynamisch änderbar''' ist (der Primary).
*<code>dns_rfc2136_name</code> ist der Schlüsselname, <code>dns_rfc2136_secret</code> der Wert aus der <code>acme-update.key</code>.
*Die Datei muss <code>600</code> sein, sonst warnt Certbot.
*Vom Webserver zum Nameserver müssen '''UDP und TCP auf Port 53''' offen sein.

==Zertifikat ausstellen==
*certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini --dns-rfc2136-propagation-seconds 10 --cert-name wiki.example.org -d wiki.example.org -d example.org --agree-tos -m admin@example.org
;Ergebnis
/etc/letsencrypt/live/wiki.example.org/fullchain.pem
/etc/letsencrypt/live/wiki.example.org/privkey.pem
;Wildcard
*certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini --dns-rfc2136-propagation-seconds 10 --cert-name example.org -d example.org -d '*.example.org'

==Bestehendes Zertifikat (HTTP) auf DNS umstellen==
Ab Certbot 4.0 (Debian 13) ohne neu auszustellen:
*certbot reconfigure --cert-name wiki.example.org --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/rfc2136.ini --dns-rfc2136-propagation-seconds 10
*grep -E "authenticator|dns_rfc2136" /etc/letsencrypt/renewal/wiki.example.org.conf
authenticator = dns-rfc2136
Certbot macht dabei einen Testlauf. Danach erneuert sich das Zertifikat mit der DNS-Challenge.

=4. Erneuerung=
*Das Debian-Paket bringt den Timer mit, Cron ist nicht nötig:
**systemctl list-timers | grep certbot
*Damit der Webserver das neue Zertifikat auch lädt, braucht es einen Hook:
**vim /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
#!/bin/sh
systemctl reload nginx
**chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
*Testen (Certbot wartet im automatischen Modus bis zu 8 Minuten per Zufallsverzögerung, mit dem Schalter geht es sofort):
**certbot renew --dry-run --no-random-sleep-on-renew
*Kontrolle:
**certbot certificates

=Fehlersuche=
{| class="wikitable"
! Meldung / Symptom !! Ursache !! Lösung
|-
| <code>REFUSED</code> oder <code>NOTAUTH</code> bei nsupdate || Schlüsselname oder <code>update-policy</code> passt nicht, oder die Adresse ist nicht der Primary || Name des Schlüssels prüfen, <code>_acme-challenge…</code> in der Policy mit '''Punkt am Ende''', <code>named-checkconf</code>
|-
| <code>update failed: NOTIMP</code> || Zone ist nicht dynamisch || <code>update-policy</code> in der Zone, Zonendatei beschreibbar
|-
| <code>TSIG error with server: tsig verify failure</code> || falsches Geheimnis oder falscher Algorithmus || Secret aus <code>acme-update.key</code> kopieren, <code>dns_rfc2136_algorithm</code> passend setzen
|-
| TXT-Eintrag ist da, Let's Encrypt findet ihn nicht || Sekundäre Nameserver haben die Zone noch nicht übernommen || <code>--dns-rfc2136-propagation-seconds</code> erhöhen, <code>also-notify</code> und Zonentransfer prüfen
|-
| Zugangsdatei wird bemängelt || Rechte zu offen || <code>chmod 600 /etc/letsencrypt/rfc2136.ini</code>
|-
| Nichts passiert, Zone lässt sich nicht von Hand ändern || Zone ist dynamisch || <code>rndc freeze</code>, ändern, <code>rndc thaw</code>
|}
;Logs
*journalctl -u named -e
*tail -f /var/log/letsencrypt/letsencrypt.log
;Was Let's Encrypt sieht
*dig +short TXT _acme-challenge.wiki.example.org @ns1.example.org
*Die Abfrage geht an die '''autoritativen''' Server der Zone, nicht an deinen Resolver.

=Sicherheit=
*Der Schlüssel erlaubt nur TXT an den <code>_acme-challenge</code>-Namen. Wer ihn stiehlt, kann Zertifikate '''für diese Namen''' bestellen, aber sonst nichts in der Zone ändern. Gib ihm trotzdem nur die Namen, die du wirklich brauchst.
*Das Geheimnis liegt nur in <code>/etc/letsencrypt/rfc2136.ini</code> (<code>600</code>) und in der Schlüsseldatei am Nameserver (<code>640</code>, <code>root:bind</code>). Nicht in ein Skript, nicht in ein Git-Repository, nicht in ein Wiki.
*Schlüssel regelmäßig tauschen: neuen mit <code>tsig-keygen</code> erzeugen, in der <code>update-policy</code> austauschen, Zugangsdatei anpassen, den alten entfernen.
*Je Server einen eigenen Schlüssel. Wird einer entwendet, sperrst du nur diesen.

=Merksatz=
Plugin statt Skript | Schlüssel nur für TXT an <code>_acme-challenge</code> | Zone wird dynamisch, Änderungen von Hand nur mit <code>rndc freeze</code> und <code>thaw</code> | Erneuerung macht der Timer, nginx lädt per Hook | erst mit <code>nsupdate</code> testen, dann mit Certbot

=Links=
*https://certbot-dns-rfc2136.readthedocs.io/
*https://letsencrypt.org/de/docs/challenge-types/
*[[Letsencrypt]]
*[[DNS challenge]]
*[[Letsencrypt DNS Verification]] (alter Weg mit Hook-Skript)
[[Kategorie:Letsencrypt]]