pixel24
Anmeldungsdatum: 20. Februar 2008
Beiträge: 473
|
Hallo zusammen, ich versuche mich gerade in LetsEncrypt einzulesen anhand dieser Dokumentation: https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-18-04 Vor der Frage sollte ich vielleicht mal kurz beschreiben was ich tun möchte. Unverschlüsselt mit Port80 habe ich das auch schon funktionell hinbekommen. Nur eben soll jetzt mit LE verschlüsselt werden. Ich habe einen externen Webserver bei All-Inkl worauf meine Domain (example.com) läuft bzw. gehostet ist. Der Webserver hat die IP 22.33.44.55. Dort habe ich zwei Subdomain eingerichtet:
gw.example.com cloud.example.com
Im Büro stellt ein IPFire mit NGINX das Gateway zum LAN da. Der IPFire hängt an einem GF Anschluss mit fixer WAN-IP (44.55.66.77) und hat die LAN-IP 192.168.xx.254. Im LAN dahinter sind zwei getrennte Server die unterschiedliche Dienste über HTTPS-Anbieten und vom Internet aus verschlüsselt angesprochen werden soll.
Dazu habe ich auf dem externen Webserver zwei A-Records gesetzt:
Der NGINX leitet nun die ankommenden Anfragen aufgrund der Subdomain weiter:
Am Ende soll folendes stehen:
Wie gesagt, ohne SSL / LE bekomme ich das ja hin. Ich wollte es nur ausführlich beschreiben da ich nicht sicher bin inwieweit es für die Planung bei den Zertifikaten relevant ist. Im NGINX-Forum und anderen habe ich Hinweise aufgeschnappt dass man beim Anlegen der Zertifikate auch Wildcards verwenden kann *.example.com. Das ist auch meine Frage. Werden die Zertifikate auf die Domain ausgestellt oer auf jeden einzeln Host der in der Domain angesprochen werden soll? Wie fange ich richtig an mit LE? Auf dem externen Webserver?, auf dem IPFire/NGINX, auf den Servern im LAN? Viele Grüße
pixel24
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
Vorneweg ein paar allgemeinere Punkte:
Zertifikate sichern Namen ab, daher brauchst du dir in Zukunft erst einmal nicht die Mühe machen, jede IP-Adresse aufzulisten. 😉 Der Server/Dienst, der unter einem bestimmten Namen auftritt, benötigt das Zertifikat und den dazu passenden privaten Schlüssel. Let's Encrypt bietet über die DNS-01 Challenge Unterstützung für Wildcard-Zertifikate an (Quelle). In einem Thread zum Thema gibt es aber auch gute Gründe gegen die Verwendung von Wildcard-Zertifikaten. Da geht es beispielsweise um die technische Möglichkeit an sich (bietet dein DNS-Provider eine API, die verwendet werden kann?) oder auch die Möglichkeit, dass jemand missbräuchlich Zertifikate für deinen ganzen Namensraum anlegen kann, ohne dass du es merkst.
Nun zu deiner Beschreibung. Was du da beschreibst, klingt sehr nach einem Reverse Proxy, sprich: Der Besucher aus dem Internet spricht eigentlich nur mit deinem nginx, der leitet die Anfragen an deine internen Server weiter und sendet auch deren Antworten wieder zurück an den Besucher von außen. Sollte ich mich da vertun, müssten wir doch nochmal über deine (öffentlichen) IP-Adressen sprechen und die Frage, ob du jeweils auf den Default Ports HTTPS sprechen willst. Unter der Annahme, dass ich dich richtig verstanden habe, brauchst du also (mindestens) zwei Server Blocks (vHosts) in deiner nginx-Konfiguration und jeder Serverblock erhält eine individuelle Zertifikatinformation. Die von dir verlinkte Anleitung behandelt genau diesen Zustand und verweist in der Einleitung noch auf ein anderes Tutorial, wo etwas detaillierter darauf eingegangen wird. In dem Reverse Proxy-Szenario würden die Server Blocks einerseits die notwendigen Direktiven enthalten müssen, um das .well-known-Verzeichnis über HTTP abzubilden (notwendig für das ACME Challenge Verfahren), andererseits die Weiterleitung an die beiden Ziel-Server (Groupware und Cloud). Du bräuchtest in dieser Situation den certbot nur auf dem nginx-Host laufen lassen und auch die Zertifikate und privaten Schlüssel würden nur dort liegen. Passt das für dich?
|
pixel24
(Themenstarter)
Anmeldungsdatum: 20. Februar 2008
Beiträge: 473
|
Cranvil schrieb: Vorneweg ein paar allgemeinere Punkte:
Zertifikate sichern Namen ab, daher brauchst du dir in Zukunft erst einmal nicht die Mühe machen, jede IP-Adresse aufzulisten. 😉 Der Server/Dienst, der unter einem bestimmten Namen auftritt, benötigt das Zertifikat und den dazu passenden privaten Schlüssel. Let's Encrypt bietet über die DNS-01 Challenge Unterstützung für Wildcard-Zertifikate an (Quelle). In einem Thread zum Thema gibt es aber auch gute Gründe gegen die Verwendung von Wildcard-Zertifikaten. Da geht es beispielsweise um die technische Möglichkeit an sich (bietet dein DNS-Provider eine API, die verwendet werden kann?) oder auch die Möglichkeit, dass jemand missbräuchlich Zertifikate für deinen ganzen Namensraum anlegen kann, ohne dass du es merkst.
Ok, soweit verstanden
Cranvil schrieb: Nun zu deiner Beschreibung. Was du da beschreibst, klingt sehr nach einem Reverse Proxy, sprich: Der Besucher aus dem Internet spricht eigentlich nur mit deinem nginx, der leitet die Anfragen an deine internen Server weiter und sendet auch deren Antworten wieder zurück an den Besucher von außen.
Ja, genau. auf dem IPfire läuft ein NGINX als Reverse-Proxy und die Anfragen werden je nach aufgerufener Subdomain an den jeweiligen internen Host weitergeliett.
Cranvil schrieb: Sollte ich mich da vertun, müssten wir doch nochmal über deine (öffentlichen) IP-Adressen sprechen und die Frage, ob du jeweils auf den Default Ports HTTPS sprechen willst.
Den Satz verstehe ich jetzt nicht ☹
Cranvil schrieb: Unter der Annahme, dass ich dich richtig verstanden habe, brauchst du also (mindestens) zwei Server Blocks (vHosts) in deiner nginx-Konfiguration und jeder Serverblock erhält eine individuelle Zertifikatinformation. Die von dir verlinkte Anleitung behandelt genau diesen Zustand und verweist in der Einleitung noch auf ein anderes Tutorial, wo etwas detaillierter darauf eingegangen wird.
Ja, das weiß ich soweit. Ich habe es ja wie gesagt unverschlüsselt schon eingerichtet, also zwei Server-Blocks. Nur eben ohne die SSL-Zeilen. Ich denke ich lasse in der Betrachtung erst mal den Zugriff per HTTPS auf den externen Webserver raus um es zu vereinfachen. Ich installiere LE auf dem IPFire auf dem ja auch NGINX läuft ein. In der NGINX-Config passe ich die entsprechenden Zeilen für SSL an bzw. füge diese ein. Wenn von extern nun auf https://gw.example.com zugegriffen wird ist ja NGINX der erste Anlaufpunkt für die verschlüsselte Verbindung. Diese verfügt über ein gültiges Zertifikat und somit gibt es im Browser keine Warnung. Auf dem internen Groupware-Server ist ja bereits ein selbst-signiertes Zertifikat vorhanden. Wen ich per Browser auf die Groupware zugreife bekomme ich beim ersten mal die Zertifikats-Warung ..... Zurück auf den externen Nutzer. Dieser kommuniziert ja mit dem dem NGINX. Das bedeutet doch ich kann auf dem internen Server mein selbst-signiertes Zertifikat belassen. Der externe Nutzer bekommt dies nicht mit? Ich hoffe ich habe alles richtig verstanden.
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
pixel24 schrieb: Cranvil schrieb: Sollte ich mich da vertun, müssten wir doch nochmal über deine (öffentlichen) IP-Adressen sprechen und die Frage, ob du jeweils auf den Default Ports HTTPS sprechen willst.
Den Satz verstehe ich jetzt nicht ☹
Wenn du genau eine öffentliche IP-Adresse hast, gibt es jeweils einen Satz TCP- und UDP-Ports. Default Ports sind die Ports, die ein Protokoll per default (durch Standardisierung oder Gewohnheit) verwendet. Beispielsweise TCP/80 für HTTP und TCP/443 für HTTPS. Wenn du zwei oder mehr Dienste über eine einzelne IP-Port-Kombination abfrühstücken willst, brauchst du also auf diesem Port einen Dienst, der diese verteilt (hier der Reverse Proxy) oder du musst andere Mechanismen verwenden (z.B. Portmappings: Port 443 verweist auf servera:443 für Anwendung A, Port 4711 verweist auf server:443, Port 8015 verweist auf serverb:4711 für Anwendung C, …). Mehr war da nicht. 😉
Cranvil schrieb:
Ich habe es ja wie gesagt unverschlüsselt schon eingerichtet, also zwei Server-Blocks. Nur eben ohne die SSL-Zeilen.
Na dann bist du doch fast fertig. Du brauchst nach meinem Verständnis "nur" certbot in etwa so zu starten:
sudo certbot --nginx -d gw.example.com -d cloud.example.com Ich habe es jetzt mangels geeigneter eigener Domains nicht ausprobieren können. Ich gehe hier davon aus, dass certbot dann tatsächlich je ein Zertifikat pro Domain anfordert, die zutreffenen Server Blocks anpasst und du dich in Ruhe wieder hinlegen kannst. Evtl. brauchst du stattdessen zwei Zeilen (je eine pro Name).
Ich denke ich lasse in der Betrachtung erst mal den Zugriff per HTTPS auf den externen Webserver raus um es zu vereinfachen. Ich installiere LE auf dem IPFire auf dem ja auch NGINX läuft ein. In der NGINX-Config passe ich die entsprechenden Zeilen für SSL an bzw. füge diese ein.
Ich verstehe nicht, was du hier genau sagen willst. Bisher ging ich davon aus, dass dein externer Webserver der nginx ist und der die Anfragen von extern als Reverse Proxy verarbeitet. Gibt es noch einen externen Webserver? Wieso sollte gerade dieser externe Webserver nicht mit einer verschlüsselten Verbindung abgesichert werden? Vor allem wenn es um Groupware und Cloud geht, würde ich eine externe Verbindung gar nicht erst zulassen, wenn ich nicht weiß, dass sie ausreichend abgesichert ist.
Auf dem internen Groupware-Server ist ja bereits ein selbst-signiertes Zertifikat vorhanden. Wen ich per Browser auf die Groupware zugreife bekomme ich beim ersten mal die Zertifikats-Warung .....
Bekommst du die Warnung auf der Groupware-Seite auch beim Zugriff von extern? Dann wäre es nochmal sinnvoll zu überprüfen, ob certbot die Zertifikate richtig beantragt und zugeordnet hat.
Das bedeutet doch ich kann auf dem internen Server mein selbst-signiertes Zertifikat belassen. Der externe Nutzer bekommt dies nicht mit?
Externe Benutzer bekommen das nicht mit, richtig. Wenn du die Möglichkeit hast, einen Split Brain-DNS einzurichten, könntest du es so einrichten, dass Zertifikat und Schlüssel vom nginx-Host regelmäßig auf Cloud- und Groupware-Server übertragen werden (spätestens jedoch nach einem Zertifikatsupdate). Dann könnten alle Anwender und Applikationen immer dieselben Adressen verwenden und das Antrainieren schlechter Angewohnheiten entfällt (selbstsignierte Zertifikate wegklicken ist nicht so gut, wie es sich zunächst anhören mag). Dieser Artikel beschreibt ganz kurz, was Split Brain-DNS ist und geht auch kurz auf Vor- und Nachteile ein. Eine weitere Alternative wäre die Einrichtung einer eigenen Zertifizierungsstelle, der deine interne Clients dann vertrauen müssen.
|
pixel24
(Themenstarter)
Anmeldungsdatum: 20. Februar 2008
Beiträge: 473
|
Cranvil schrieb: Sollte ich mich da vertun, müssten wir doch nochmal über deine (öffentlichen) IP-Adressen sprechen und die Frage, ob du jeweils auf den Default Ports HTTPS sprechen willst.
Wenn du genau eine öffentliche IP-Adresse hast, gibt es jeweils einen Satz TCP- und UDP-Ports. Default Ports sind die Ports, die ein Protokoll per default (durch Standardisierung oder Gewohnheit) verwendet. Beispielsweise TCP/80 für HTTP und TCP/443 für HTTPS. Wenn du zwei oder mehr Dienste über eine einzelne IP-Port-Kombination abfrühstücken willst, brauchst du also auf diesem Port einen Dienst, der diese verteilt (hier der Reverse Proxy) oder du musst andere Mechanismen verwenden (z.B. Portmappings: Port 443 verweist auf servera:443 für Anwendung A, Port 4711 verweist auf server:443, Port 8015 verweist auf serverb:4711 für Anwendung C, …). Mehr war da nicht. 😉
Ja, das weiß ich. Deshalb ja die ganze Aktion mit NGINXCranvil schrieb: Cranvil schrieb:
Ich verstehe nicht, was du hier genau sagen willst. Bisher ging ich davon aus, dass dein externer Webserver der nginx ist und der die Anfragen von extern als Reverse Proxy verarbeitet. Gibt es noch einen externen Webserver? Wieso sollte gerade dieser externe Webserver nicht mit einer verschlüsselten Verbindung abgesichert werden? Vor allem wenn es um Groupware und Cloud geht, würde ich eine externe Verbindung gar nicht erst zulassen, wenn ich nicht weiß, dass sie ausreichend abgesichert ist.
Siehe: pixel24 schrieb: Im Büro stellt ein IPFire mit NGINX das Gateway zum LAN da. Der IPFire hängt an einem GF Anschluss mit fixer WAN-IP (44.55.66.77) und hat die LAN-IP 192.168.xx.254. Im LAN dahinter sind zwei getrennte Server die unterschiedliche Dienste über HTTPS-Anbieten und vom Internet aus verschlüsselt angesprochen werden soll.
Dazu habe ich auf dem externen Webserver zwei A-Records gesetzt:
Der NGINX leitet nun die ankommenden Anfragen aufgrund der Subdomain weiter:
Am Ende soll folendes stehen:
NGINX läuft auf der Firewall im Büro. Auf dem externen Domain-Server sind lediglich die Subdomain eingerichtet und der A-Record gesetzt damit gw.example.com und cloud.example.com auf die WAN-IP der Firewall im Büro zeigt. Ich versuche mich gerade in LetsEncrypt etwas einzulesen um es dann auf der Firewall zu installieren/einzurichten. Anschließend den NGINX so konfigurieren dass er diese Zertifikate nutzt. Die internen Server (Groupware & Cloud) belasse ich mit ihren selb-signierten Zertifikaten. Ich werde berichten wie es klappt ☺
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
pixel24 schrieb: Ja, das weiß ich. Deshalb ja die ganze Aktion mit NGINXCranvil schrieb:
Super, das du meine Klarstellung auf dein "Den Satz verstehe ich jetzt nicht" nicht abfällig mit einem "Ja, das weiß ich." bewertest. Das hätte ich echt als unhöflich empfunden. Also danke für deine Rücksichtnahme!
Siehe:
Ich hoffe, ich bekomme nicht gleich wieder ein nahezu vollständiges Zitat deines ersten Beitrags. pixel24 schrieb: Ich denke ich lasse in der Betrachtung erst mal den Zugriff per HTTPS auf den externen Webserver raus um es zu vereinfachen.
Ich habe das Zitat nochmal etwas reduziert, denn grundsätzlich ist bekannt, dass du einen nginx auf der Firewall laufen hast und mindestens zwei Webserver innerhalb deines Netzwerks. Was bisher nicht behandelt wurde, ist ein externer Webserver. Meine Frage war weniger die Bitte um ein nahezu vollständiges Zitat deines ersten Beitrags (entschuldige die Wiederholung), sondern eine Antwort im Sinne von "Damit meinte ich den Aufruf von Groupware/Cloud über die externe URL von den internen Clients aus". Das ist erst einmal nur ein Beispiel und ich nehme an, das ist es, was du meintest. Ich weiß es allerdings nicht, weil ich stattdessen ein nahezu vollständiges Zitat deines ersten Beitrags erhalten habe.
NGINX läuft auf der Firewall im Büro. Auf dem externen Domain-Server sind lediglich die Subdomain eingerichtet und der A-Record gesetzt damit gw.example.com und cloud.example.com auf die WAN-IP der Firewall im Büro zeigt.
Nur der Vollständigkeit halber: Domain-Server im Sinne von DNS-Server (bzw. indirekte DNS-Konfiguration via Webpanel à la Plesk u.ä.)?
Ich versuche mich gerade in LetsEncrypt etwas einzulesen um es dann auf der Firewall zu installieren/einzurichten. Anschließend den NGINX so konfigurieren dass er diese Zertifikate nutzt. Die internen Server (Groupware & Cloud) belasse ich mit ihren selb-signierten Zertifikaten. Ich werde berichten wie es klappt ☺
Viel Erfolg.
|
pixel24
(Themenstarter)
Anmeldungsdatum: 20. Februar 2008
Beiträge: 473
|
Hallo, ich wollte auf keinen Fall abfällig oder unhöflich sein. Sollte dass so rüber gekommen sein entschuldige ich mich! Ich hatte den Abschnitt mit dem Satz:
Cranvil schrieb: Sollte ich mich da vertun, müssten wir doch nochmal über deine (öffentlichen) IP-Adressen sprechen und die Frage, ob du jeweils auf den Default Ports HTTPS sprechen willst.
nicht verstanden bzw. es war mir nicht ganz klar was Du meinst. Anschließend hast Du es dann anders formuliert:
Cranvil schrieb: Wenn du zwei oder mehr Dienste über eine einzelne IP-Port-Kombination abfrühstücken willst, brauchst du also auf diesem Port einen Dienst, der diese verteilt (hier der Reverse Proxy) oder du musst andere Mechanismen verwenden (z.B. Portmappings: Port 443 verweist auf servera:443 für Anwendung A, Port 4711 verweist auf server:443, Port 8015 verweist auf serverb:4711 für Anwendung C, …). Mehr war da nicht. 😉
hast wusste ich was Du meinst.
Und da ich ja mit Port-Mapping gearbeitet habe aber dies für genau diesen Fall nicht geht und ich es mit NGINX und Port 80 (zwei interne Server sind auf Port 80 von außen unter der festen WAN-IP meines Gateways erreichbar) ja schon am Laufen hatte kam ich zu der Antwort: "Ja, das weiß ich ..." Und das es ein Missverständnis gab wurde mir bei dieser Antwort klar: Cranvil schrieb:
Ich verstehe nicht, was du hier genau sagen willst. Bisher ging ich davon aus, dass dein externer Webserver der nginx ist und der die Anfragen von extern als Reverse Proxy verarbeitet. Gibt es noch einen externen Webserver? Wieso sollte gerade dieser externe Webserver nicht mit einer verschlüsselten Verbindung abgesichert werden? Vor allem wenn es um Groupware und Cloud geht, würde ich eine externe Verbindung gar nicht erst zulassen, wenn ich nicht weiß, dass sie ausreichend abgesichert ist.
Ich habe dann doof zitiert weil ich doch eigentlich schon beschrieben hatte wie die Konstellation ist: externen Webserver, Büro-Gateway mit installiertem NGINX und fester WAN-IP ... Oder die Verwirrung kam zustande weil ich, wenn ich von: "Zugriff per HTTPS auf den externen Webserver" spreche nicht den Webserver auf meinem Gateway/NGINX meine sondern den externen wo die Domain geostet ist. Das Thema mit LetsEncrypt ist für mich halt komplett neu und nochmal. Wenn ich mich in irgend einer Form dumm ausgedrückt habe tut es mir leid. Ich bin immer froh hier so tolle Hilfe zu bekommen ☺
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
Ich war auch nicht besonders fair und vor allem ein wenig unaufmerksam, da ich den Webserver bei all-inkl komplett ausgeblendet hatte. ☹ Du scheinst dort ja die Subdomains so einrichten zu können, dass die Anfragen auf deinem Router/nginx ankommen. Dann brauchst du dort nichts weiter konfigurieren. Und je nach Paket, was du dort gebucht hast, wirst du dort keinen Reverse Proxy einrichten können und vermutlich auch nicht wollen. Immerhin läuft dann dein gesamter Traffic für die beiden Dienste über deinen Webhoster, was vielleicht zu viel für das im Paket inkludierte Datenvolumen ist.
|
pixel24
(Themenstarter)
Anmeldungsdatum: 20. Februar 2008
Beiträge: 473
|
Funktionell habe ich es in einer Test-Umgebung auch jetzt mal eingerichtet bekommen. Da ich verstehen möchte wie es funktioniert habe ich (völlig losgelöst von allen bisher beschrieben Schritten) auf meinem Webserver bei All-Inkl für meine dort gehostet Domain "example.com" im dortigen Verwaltungs-Tool Let's Encrypt für genau dies Domain eingerichtet. Was ja mit wenigen Klicks geht. Wenn ich unterhalb der Domain (im Backend bei All-Inkl) die SSL-Einstellungen anschaue wurde das Zertifikat so: 1
2
3
4
5
6
7
8
9
10
11
12
13
14 | Inhaltsdaten CRT
Gemeinsamer Name [CN]: example.com
Zertifikat ausgestellt für: example.com, www.example.com
Gültig: 2019-12-17 bis 2020-03-16 (noch 89 Tage gültig, verlängert sich automatisch)
SHA1 Fingerabdruck: **************
Schlüsselstärke: 2048 bit
Signaturalgorithmus: sha256WithRSAEncryption
signiert von: Let's Encrypt, Let's Encrypt Authority X3
|
Was hat es denn mit "Zertifikat ausgestellt für" genau auf sich. Ist das jetzt EIN Zertifikat das für "example.com" und "www.example.com" gültig ist? Oder ist das nun ein Wilcard-Zertifikat?
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
Das ist ein Zertifikat, das für die beiden Hostnamen example.com und www.example.com gilt. Im Falle eines Wildcard-Zertifikats würde dort *.example.com stehen.
|
pixel24
(Themenstarter)
Anmeldungsdatum: 20. Februar 2008
Beiträge: 473
|
ok, verstehe. Dort im Webinterface bei All-Inkl, wo ch dieses Zertifikat anschauen kann finde ich noch:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57 | ** Inhaltsdaten der Brückenzertifikate **
SSL Zertifikat #1: Let's Encrypt, Let's Encrypt Authority X3
signiert von: Digital Signature Trust Co., DST Root CA X3
** Zertifikatsdaten für Apache/mod_ssl **
CSR:
-----BEGIN CERTIFICATE REQUEST-----
MIICrTCCAZUCAQAwFjEUMBIGA1UEAwwLZ2Voci1lZHYuZGUwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQC9+GyqaPVx2Nkn7a2VDUJTIV1FKSkMESkDzUeX
...
...
TJSlOjX7ximP8uRE97cZZlljIssMuha8eIaeHTcwLT6bNGTKIaHUTh37iapDOxzt
9KxeMzU9+QrSl5E05C1hF7CcJgi+R/QEFN74Ui7M8/j6FokYC6PMMeY+NlDALEHm
MLt2zHax1n1/4o3yZsuC0zw=
-----END CERTIFICATE REQUEST-----
KEY:
-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQC9+GyqaPVx2Nkn
7a2VDUJTIV1FKSkMESkDzUeXvddZ2gkhi2ZbWE1ml4tawGkw/w7h5l/1i/pLIoda
...
...
nKQraveKDllkw+iQY3Dk76opuj5/2Vc0cUkLVmJCHBfLqBVPYAjtvd3QDsSy05Zg
e4wgaq/JQLmEdGsfu/wF6Gtn
-----END PRIVATE KEY-----
KEY passphrase: leer
CRT:
-----BEGIN CERTIFICATE-----
MIIFXjCCBEagAwIBAgISBMrTi6uYSTKYh4SxOVFE1FgHMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
...
...
iE1/vjhSJSYI/oQtQB3DRgqHNK7rbH80bmaNVjso21L9SzfQV4ChmoxvQH5RJ37u
wOX4qaewhoB/1VCfd+Zgf3Z28R9taH6sD10U+TvJLnBU9A==
-----END CERTIFICATE-----
Brückenzertifikate:
-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
...
...
X4Po1QYz+3dszkDqMp4fklxBwXRsW10KXzPMTZ+sOPAveyxindmjkW8lGy+QsRlG
PfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6
KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==
-----END CERTIFICATE-----
|
Kann ich mit diesen Daten einen nsupdate duerchführen? Also die Validierung vornehmen?
Validation Methods Let’s Encrypt can validate by checking the contents of a TXT record in DNS, or by fetching a file in a known location from a web server running on the hostname it is validating. The nsupdate method uses RFC2136 style DNS updates to populate a TXT record in DNS to validate ownership of the domain. We recommend using this method as it does not require external inbound access, so it can be used for internal systems that do not allow or cannot receive Internet traffic. Before starting, an appropriate DNS key and settings must be in place in the DNS infrastructure for the domain to allow the host to update a TXT DNS record for _acme-challenge.<domain name>.
Dafür muss man ja im DNS einen TXT-Record:
| _acme-challenge.<domain name>
|
setzen was ich ja dort kann. Nur kann ich mir dem im Zertifikat für (example.com, www.example.com) angezeiten Key auch das nsupdate durchführen? Oder sind diese Key's für etwas anderes?
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
pixel24 schrieb: -----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
Unterlasse es bitte, deine privaten Schlüssel in öffentlich zugänglichen Foren zu posten - eigentlich solltest du das auch nicht in privaten Foren machen. Kurz: Lass es einfach! Was du da so eifrig eingefügt hast, sind zwei Drittel deines BASE64-Kodierten privaten Schlüssels 😳 😬 . Im schlimmsten Fall ist der nicht einmal mit einem Kennwortschutz versehen, was bedeutet, dass er effektiv im Klartext dort steht. Am besten beschäftigst du dich mit der Frage, wie du dein neues Zertifikat bzw. den dahinter stehenden privaten Schlüssel als kompromittiert melden kannst und baust die Zertifikate mit neuem privaten Schlüssel gleich wieder neu auf.
Kann ich mit diesen Daten einen nsupdate duerchführen? Also die Validierung vornehmen?
Das müsstest du den Betreiber des DNS-Servers fragen, der deine DNS-Domain verwaltet. Ich vermute all-inkl und ich vermute, nein. nsupdate ist nach meinem Verständnis für dynamisches DNS gedacht (ein anderes dynamische DNS, nicht das no-ip dynamische DNS), welches in der Regel nur in internen Netzwerken zugelassen wird und auch nur, wenn die Beteiligten wissen, was sie tun - oder eben genau das Gegenteil ☹. Was aus der von dir zitierten Beschreibung für dich vielleicht nicht deutlich genug hervor geht: Dieser Mechanismus wird für Leute empfohlen, die ihre öffentlichen DNS-Domains selbst hosten, aber die zu zertifizierenden Server nicht öffentlich zugänglich machen. Der certbot könnte also als interner Client eine Challenge in den DNS-Server platzieren, ohne dass der Zuständige für IT-Sicherheit einen vorzeitigen Herztod erleidet. Alternativ kannst du prüfen, ob du die Challenge jedes Mal händisch in dein DNS-Interface übertragen kannst und willst. Können, weil nicht jeder Hoster TXT RR zulässt. Ich müsste selbst erst herausfinden, wo der die einzutragende Challenge dann ausgibt - wenn das überhaupt so geht.
Nur kann ich mir dem im Zertifikat für (example.com, www.example.com) angezeiten Key auch das nsupdate durchführen? Oder sind diese Key's für etwas anderes?
Kurz: Nein, kannst du nicht. Ja, ist für etwas anderes (Beschreibung unten). Wie oben bereits angesprochen, ist eine der Sektionen, die so unscheinbar PRIVATE KEY heißt, dein GEHEIMER Schlüssel (ich kann das gar nicht laut genug schreien 😠). Damit signiert der Server seine Nachrichten, entschlüsselt an ihn versendete verschlüsselte Botschaften und handelt gewissermaßen auch den sicheren Kommunikationskanal mit dem Client aus. Alles in allem schon nicht so gut, den auch nur anteilig zu veröffentlichen. 🙄 Die anderen Dinge sind die Zertifizierungsanfrage, das eigentliche Zertifikat und die verschiedenen Zwischenzertifikate, die ein Client unter Umständen benötigt, um dein Zertifikat bis zur Stammzertifizierungsstelle zurückverfolgen zu können. Alle jeweils in BASE64 kodiert, damit die Dinger nicht durch die Verwendung unterschiedlicher Zeichenkodierungen kaputtgehen. Wenn ich mich noch an die openssl-Kommandos erinnern könnte, würde ich dir diese auch noch mitgeben. Ich vermute, dass diese Blöcke bereits irgendwo weiter oben in dekodierter und aufgehübschter Form stehen. So, jetzt hau ich mir die Hirse mit Raki zu… Private Schlüssel posten… Dass ich sowas hier erleben muss! *Motzmeckergrummelfluch* Edit: Keine Sorge, ich bin nicht wirklich sauer. Ich wollte nur darauf aufmerksam machen, damit es bei einem Oopsi bleibt und nicht irgendwann ein Oops wird, wenn du es nicht gebrauchen kannst. 😈 😇 😉
|
pixel24
(Themenstarter)
Anmeldungsdatum: 20. Februar 2008
Beiträge: 473
|
Formatierter TextCranvil schrieb:
pixel24 schrieb:
Unterlasse es bitte, deine privaten Schlüssel in öffentlich zugänglichen Foren zu posten - eigentlich solltest du das auch nicht in privaten Foren machen. Kurz: Lass es einfach! Was du da so eifrig eingefügt hast, sind zwei Drittel deines BASE64-Kodierten privaten Schlüssels 😳 😬 . Im schlimmsten Fall ist der nicht einmal mit einem Kennwortschutz versehen, was bedeutet, dass er effektiv im Klartext dort steht. Am besten beschäftigst du dich mit der Frage, wie du dein neues Zertifikat bzw. den dahinter stehenden privaten Schlüssel als kompromittiert melden kannst und baust die Zertifikate mit neuem privaten Schlüssel gleich wieder neu auf.
Also:
Sind das 4 von 14 Zeilen
2. wurde der Inhalt verändert .... ganz doof bin ich auch ned!
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
Puh, dann erschreck mich doch nicht so! 😉 Ehrlich gesagt, hatte es mich auch ein wenig überrascht, das von dir zu sehen. Falls jemand über den Thread stolpert, weiß er wenigstens, woran er ist. Haben sich zwischendurch noch Fragen zum Thema ergeben oder läuft schon alles wie angedacht?
|
pixel24
(Themenstarter)
Anmeldungsdatum: 20. Februar 2008
Beiträge: 473
|
Cranvil schrieb: Haben sich zwischendurch noch Fragen zum Thema ergeben oder läuft schon alles wie angedacht?
War mit dem Austausch des Virtualisierungs-Host (Wechsel Ubuntu auf Proxmox) beschäftigt und komme erst jetzt wieder dazu. Bin gerade dabei mich mehr in's Thema oder besser gesagt die Themen einzulesen und habe heute auch mal eine Mail an den Provider (All-Inkl) geschrieben ob dieser eine API für nsupdate (schreiben des Challange in _acme-challenge.<domain name>) anbietet. Ich denke mittels nsupdate wäre die sauberste Lösung. Ich werde berichten ☺
|