Guten Tag zusammen.
Ich betreibe zuhause auf einer virtuellen Maschine einen ApacheWebServer. Dieser WebServer verfügt über LetsencryptZertifikate. Sie sind beim Apachen eingetragen und liegen im Verzeichnis /etc/letsencrypt/live - natürlich auf meinem Server.
Meine ipv64Domain funktioniert einwandfrei. Die DynDNS wird sauber upgedatet.
Via pfSense habe ich jetzt für diese Domain Zertifikate angefordert. Hat auch funktioniert. Wie versorge ich jetzt meinen Apachen mit diesen via pfSense erstellten, aktuellen Zertifikaten? Mit einem 301Weiterleitungseintrag in der SSLKonfigurationsdatei meines Apachen funktioniert das offenbar nicht so, wie ich mir das erhofft habe.
Ich stehe auf dem Schlauch.
Bisher war das alles kein Problem, da ich über eine feste IP verfügte. Das ist jetzt flach gefallen, und der Einsatz von DynDNS wurde erforderlich.
Wie hast du denn bisher die Zertifikate erneuert? Per acme.sh?
Nutze nginx statt apache, aber das Erzeugen der Zertifikate sollte davon ja unabhängig sein.
Du kannst auf der pfSense auch einen Reverse Proxy mit HAProxy einrichten.
Danke für Dein Interesse.
Ich bin IndianerFan. 
Da ich bisher nur auf die Umstände „SelbstHoster“ angewiesen war, was ich aufrechterhalten werde, hat mir eine httpChallenge statt einer DNSChallenge völlig ausgereicht. Nun aber war ich gezwungen, auf dynamische Adressen auszuweichen - DSL aus, Glasfaser an. Providerwechsel etc.
Nun beziehe ich die Zertifikate via pfSense für meinen ipv64Account
Das funktioniert alles sauber, und die wechselnden Adressen werden zuverlässig upgedatet.
Das sagt mir jetzt nichts
Ich bin meinem Problem - glaube ich - mittlerweile auf die Spur gekommen.
Wenn es läuft, gebe ich hier einen Überblick über die gesamte Problemetik, da das von größerem Interesse sein dürfte.
Doch zur Zeit muss ich noch etwas warten, da ich wegen zu häufiger Zertifikatsabfragen - abfragen, löschen, abfragen, löschen - eine Weile warten muss, bis ich meinen ipv64Account wieder mit einem Zertifikat ausstatten darf.
Wenn man einen eigenen WebServer betreibt, die feste IP wegen Anschlusskündigung - hier Telekom - wegfällt, braucht man einen DynDNSAnbieter, in meinem Fall ipv64.net.
Nach wie vor bleibt meine Ursprungsdomain jedoch bei der Telekom registriert, da ich meine MailAdressen ohne großes Hin und Her behalten möchte. Wer eine Domain bei der Telekom hat, bekommt nach der AnschlussKündigung eine dynamische IPAdresse zugewiesen, die aber auf den DSLAnschluss verweist. Dafür zahle ich monatlich 5 €. Soweit so gut.
Solange die Telekom die Domain verwaltet, macht eine Eintragung dieser eigenen Domain bei ipv64.net keinen Sinn. NS bad. Die Telekom ermöglicht in ihrer DomainVerwaltung keinen NSEintrag, Folglich habe ich mir bei ipv64.net eine neue DomainAdresse zugelegt, worüber jetzt die IPAdressen synchronisiert werden.
Damit die allgemeine Adressabfrage dieser Domain „host…“ funktioniert, habe ich die TelekomDomain via DomainVerwaltung bei der Telekom an meine ipv64.netDomain weitergeleitet. Damit werden die hostAbfragen der ipv64Domain korrekt beantwortet, mit der jeweiligen neuen IPAdresse.
Ohne diese Weiterleitung präsentierten mir die hostAbfragen zu der neuen ipv64Domain keine Antwort. Das Problem war also gelöst.
Als weiterer Schritt war ein 301Redirect in meinem Apache erforderlich. Den hatte ich falsch gesetzt, undzwar so, dass immer nur die Startseite meiner WebPage, und das auch noch fehlerhaft, erschien, die Links aber nicht funktionierten.
Dafür bedarf es eines genaueren Redirects, damit auch die Unterverzeichnisse angesprochen werden können, die Seite korrekt dargestellt wird und die Links funktionieren.
Ich stelle diesen Abschnitt hier mal vor:
ServerName schlagkeinentot.de
ServerAlias www.schlagkeinentot.de
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
RedirectMatch permanent ^/(.*)$ https://schlagkeinentot.ipv64.de/$1
Das dürfte das Problem lösen.
Doch, wie bereits erwähnt, muss ich mir erst wieder per pfSense für meine ipv64.netDomain ein Zertifikat installieren, damit https funktioniert. Wie man das macht ist hier sehr gut beschrieben. Bis dahin sind jedenfalls keine Zugriffe auf diese Seiten möglich, da das Zertifikat noch fehlt.
Ich hoffe, einigermaßen verständlich zu sein.
Ist bei mir länger her mit Apache, aber die Config muss ungefähr so aussehen:
<VirtualHost *:80>
DocumentRoot "/var/www/html"
ServerName your.domain.example.com
Redirect permanent / https://your.domain.example.com/
</VirtualHost>
<VirtualHost *:443>
DocumentRoot "/var/www/html"
ServerName your.domain.example.com
SSLEngine on
SSLCertificateFile /path/to/your_domain_name.crt
SSLCertificateKeyFile /path/to/your_private.key
SSLCertificateChainFile /path/to/DigiCertCA.crt
</VirtualHost>
Hatte mir damals die Zertifikate von Letsencrypt via Certbot gezogen. Mit certbot —apache wurde dann automatisch die passende Config, wie oben, im Apache gesetzt.
So sieht es aus.
Läuft bei mir seit ca 15 Jahren.
Jedoch habe ich während dieser Zeit keine RedirectRegel benötigt, die auf ein externes Ziel zeigt, wobei bestimmte CodeSchnipsel von Bedeutung sind.
Seitdem ich auf DynDNS angewiesen bin, seit 1. August sozusagen, sieht das etwas anders aus.
Weitergeholfen hat mir dieser Artikel, um meine nach wie vor bei mir gehostete WebPage wieder sichtbar und funktionstüchtig zu halten.
Doch wie bereits erwähnt, warte ich zur Zeit noch auf die Freigabe des erneuten Abrufes der LetsencryptZertifikate, da ich das Limit dieses Dienstes überschritten habe.
Maßgeblich ist im obigen Artikel Beispiel 1 - Wechsel zu einer anderen Domäne.
Meine TanteGoogleAbfragen haben gezeigt, dass eine Menge „Kollegen“ ähnliche Probleme haben, aber kaum die richtigen Antworten finden.
Ich hoffe, dass ich Erfolg habe und anderen weiterhelfen kann?
Wer also eine Domain mit Hllfe einer anderen abbilden muss, so z.B. bei einem Wechsel von einem Provider mit fester IPAdresse zu einem Netzbetreiber mit dynamischer IPAdresse für den Internetanschluss, steht plötzlich vor diesem Problem. Betreibt er ausschließlich eine einzelne Netzseite, z. B. Nextcloud oder Adminer respektive PHPmyadmin, zum Zwecke der Verwaltung von Datenbanken, reicht die einfache RedirectRegel völlig aus. Wenn aber z.B. ein ganzes WordpressVerzeichnis mit Unterverzeichnissen auf dem eigenen Server angesprochen werden muss, damit interne Links funktionieren und der Zugriff auf Dateien, die die korrekte Darstellung der Seite steuern, erforderlich ist, bedarf es der hier beschriebenen Lösung.
Die andere Möglichkeit, DNSChallengeZertifikate mittels certbot auf meinem eigenen Server abzulegen, scheidet bei mir aus. Da vertraue ich mich ipv64.net an.
Und bei der Telekom kann man zwar CNAMEEinträge - und diese auch nicht für die Domain selbst, sondern nur für SubDomains - anlegen, aber keine NSServer eintragen. Daraus ergibt sich, dass die Adressabfrage mittels ‚host‘ für die ipv64.netUmgebung nicht beantwortet werden. Jeder Provider bereitet seine eigenen Salate auf seine Weise vor.
Lange Rede, kurzer Sinn. In meinem Fall sieht das folgendermaßen aus
- TelekomRegistrarDomäne bisskultur.de komplett weiterleiten auf https://bisskultur.ipv64.de
- Im Apachen unter /etc/apache2/sites-enabled/bisskultur-ssl.conf
Redirect permanent https://bisskultur.de https://bisskultur.ipv64.de
austauschen gegen
RedirectMatch permanent ^/(.*)$ https://bisskultur.ipv64.de/$1
Die Domänen muss man natürlich durch sein jeweils eigenes „Pärchen“ ersetzen.
Man kann natürlich auch beide Domains auf seinem Apachen verwalten, ist aber etwas umständlicher.
Ich mache meinen Salat „bisskultur.de“ und überlasse ipv64.net ihren Salat bisskultur.ipv64.de. Das ist für meine Begriffe die sauberste Lösung.
Außerdem ist pfSense ein interessantes Projekt.
Da meine Seite bisher mit SSL A+ bewertet wurde (StrictTransportSecurity), bin ich gespannt, wie das in Zukunft aussieht. Bei ausbleibendem Erfolg müsste ich tatsächlich beide Seiten auf meinem eigenen Server verwalten. Warten wir’s ab.
Adiós muchachos!
