55283
Dec 25, 2007, updated at Dec 27, 2007 (UTC)
29450
8
0
Zertifikat erneuern Apache Web-Server
Hi
Hab mir grad nen Apache Server mit allen drum und dran installiert und jetzt wenn ich mit https verbinde kommt das hier:
Screen:
http://img184.imageshack.us/img184/8725/abgelaufenoh1.png
http://img205.imageshack.us/img205/310/52513992dn1.png
Wie kann ich das Zertifikat erneuern/verlängern?
Schonmal danke im Voraus!
Gruß Bernie.
Hab mir grad nen Apache Server mit allen drum und dran installiert und jetzt wenn ich mit https verbinde kommt das hier:
Screen:
http://img184.imageshack.us/img184/8725/abgelaufenoh1.png
http://img205.imageshack.us/img205/310/52513992dn1.png
Wie kann ich das Zertifikat erneuern/verlängern?
Schonmal danke im Voraus!
Gruß Bernie.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 76616
Url: https://administrator.de/contentid/76616
Printed on: April 18, 2024 at 06:04 o'clock
8 Comments
Latest comment
Das Webserver Zertifikat hat mehrere "Funktionen".
1. Es enthält den "öffentlichen Schlüssel", mit dem die Daten die der Client zum Server schickt verschlüsselt werden
2. Es beglaubigt die Identität des Webservers, wenn es von einer Zertifizierungsstelle, die das Zertifikat signiert hat, und der der client vertraut, ausgestellt wurde. Dazu macht vergleicht der Client das im Zertifikat enthaltene Servername mit dem DNS Name des Webservers. Stimmt der Name im Zertifikat nicht mit dem DNS Namen überein, kommt die Fehlermeldung. Oder aber das zertifikat ist "abgelaufen" - Zertifikate sind zeitlich begrenzt gültig.
Dennoch funktioniert Funktion 1 - du musst nur die Fehlermeldungen akzeptieren.
Zum erneuern machst Du einen Zertifikats-Request, den eine vertrauenswürdige CA signieren muss und Dir ein aktualisiertes Zertifikat ausstellt. Da Du die localhost IP ansprichst, wird die DNS Fehlermeldung jedoch weiterhin erscheinen, solange der Name im Zertifikat nicht mit dem DNS Namen des Servers übereinstimmt. Man kann auch eine eigene Zertifizierungsstelle (PKI) aufsetzen - dann müssen die Clients jedoch in ihren Webbrowser das Root-CA Zertifikat importieren, das die Zertifikate signiert hat, sonst bekommen sie jedesmal die Fehlermeldung, das Zertifikat wäre von einer nicht vertrauenswürdigen CA ausgestellt worden.
1. Es enthält den "öffentlichen Schlüssel", mit dem die Daten die der Client zum Server schickt verschlüsselt werden
2. Es beglaubigt die Identität des Webservers, wenn es von einer Zertifizierungsstelle, die das Zertifikat signiert hat, und der der client vertraut, ausgestellt wurde. Dazu macht vergleicht der Client das im Zertifikat enthaltene Servername mit dem DNS Name des Webservers. Stimmt der Name im Zertifikat nicht mit dem DNS Namen überein, kommt die Fehlermeldung. Oder aber das zertifikat ist "abgelaufen" - Zertifikate sind zeitlich begrenzt gültig.
Dennoch funktioniert Funktion 1 - du musst nur die Fehlermeldungen akzeptieren.
Zum erneuern machst Du einen Zertifikats-Request, den eine vertrauenswürdige CA signieren muss und Dir ein aktualisiertes Zertifikat ausstellt. Da Du die localhost IP ansprichst, wird die DNS Fehlermeldung jedoch weiterhin erscheinen, solange der Name im Zertifikat nicht mit dem DNS Namen des Servers übereinstimmt. Man kann auch eine eigene Zertifizierungsstelle (PKI) aufsetzen - dann müssen die Clients jedoch in ihren Webbrowser das Root-CA Zertifikat importieren, das die Zertifikate signiert hat, sonst bekommen sie jedesmal die Fehlermeldung, das Zertifikat wäre von einer nicht vertrauenswürdigen CA ausgestellt worden.
thx und wie mach ich das jetzt?^^ kenn mich auf den gebiet noch nicht so aus..
Wie verlängere ich den jetzt das Zertifikat und den DNS-Namen?
Wie verlängere ich den jetzt das Zertifikat und den DNS-Namen?
In drei Sätzen zu erklären wie eine PKI funktioniert wird schwierig.
Im Grunde musst Du
Hier gibts dazu nähere Informationen. Schwer ist es eigentlich nicht, man muss das ganze erstmal jedoch kapieren, den Sinn erfassen, dann kann man es mit den genannten Befehlen recht schnell umsetzen.
http://www.jfranken.de/homepages/johannes/vortraege/apache_inhalt.de.ht ...
Letztendlich ist der Sinn der ganzen Aktion folgender:
Wenn Du mit Deinem Browser auf einen Webserver gehst, z. B. https://postbank.de sendet der Webserver zunächst sein Server-Zertifikat an Deinen Browser.
Das Zertifikat ist zum einen eine Art "Ausweis" mit der die Identität des Webservers beglaubigt werden soll, zum anderen enthält das Zertifikat den so genannten "öffentlichen Schlüssel" des Webservers. Der Webserver hält nämlich auch den passenden (!) "privaten Schlüssel" parat. Alles, was mit dem öffentlichen schlüssel verschlüsselt wird, kann NUR der private Schlüssel des Webservers entschlüsseln, und KEIN anderer Schlüssel der Welt.
Darum ist es essentiel, den privaten Schlüssel zu schützen und niemals herauszugeben.
Der private Schlüssel liegt in einem Verzeichnis auf dem Webserver (glaube /etc/apache/ssl oder so ähnlich).
Wie weiss ich jedoch, dass ich - wenn ich auf https://postbank.de navigiere, dass ich WIRKLICH auf dem postbank Server lande, und nicht auf einem Fake-Server aus Rumänien, oder dass nicht jemand in meinem lokalen Netz gerade eine "Man-in-the-Middle-Attacke" macht und meine Zugangsdaten abfangen will?
Der Client Browser enthält eine ganze Reihe von vertrauenswürdigen Root CA Zertifikaten, z. B. von Verisign. JEDES Webserverzertifikat, das z. B. von Verisign SIGNIERT wurde, wird automatisch als vertrauenswürdig eingestuft, man erhält keine Fehlermeldung wenn man so eine Webseite aufruft.
Sendet der Webserver jedoch ein Zertifikat, das NICHT von einer vertrauenswürdigen Root CA signiert wurde - dann ist das Zertifikat nicht vertrauenswürdig. Es KANN sich also um eine Fälschung handeln, oder der Webserver-Admin ist ein Schlamper (meist trifft zweites zu) oder er hat keine Ahnung von der Materie.
Wenn ich keine teure Signierung von Verisign kaufen will, da ich keine Kohle habe, dann mache ich eben meine eigene Root CA. Da jedoch die Clients diese Root CA nicht kennen und ihr auch nicht vertrauen, müssen die Clients in ihren Browser das Root CA meiner eigenen CA importieren - beim Aufruf einer Webserver Webseite, die ein von meiner eigenen Root CA signiertes Webserverzertifikat anzeigt, wird dann keine Fehlermeldung erscheinen, dass das Zertifikat nicht vertrauenswürdig wäre.
Im Grunde musst Du
- eine Root CA aufsetzen
- auf dem Webserver einen Zertifikatsrequest generieren
Hier gibts dazu nähere Informationen. Schwer ist es eigentlich nicht, man muss das ganze erstmal jedoch kapieren, den Sinn erfassen, dann kann man es mit den genannten Befehlen recht schnell umsetzen.
http://www.jfranken.de/homepages/johannes/vortraege/apache_inhalt.de.ht ...
Letztendlich ist der Sinn der ganzen Aktion folgender:
Wenn Du mit Deinem Browser auf einen Webserver gehst, z. B. https://postbank.de sendet der Webserver zunächst sein Server-Zertifikat an Deinen Browser.
Das Zertifikat ist zum einen eine Art "Ausweis" mit der die Identität des Webservers beglaubigt werden soll, zum anderen enthält das Zertifikat den so genannten "öffentlichen Schlüssel" des Webservers. Der Webserver hält nämlich auch den passenden (!) "privaten Schlüssel" parat. Alles, was mit dem öffentlichen schlüssel verschlüsselt wird, kann NUR der private Schlüssel des Webservers entschlüsseln, und KEIN anderer Schlüssel der Welt.
Darum ist es essentiel, den privaten Schlüssel zu schützen und niemals herauszugeben.
Der private Schlüssel liegt in einem Verzeichnis auf dem Webserver (glaube /etc/apache/ssl oder so ähnlich).
Wie weiss ich jedoch, dass ich - wenn ich auf https://postbank.de navigiere, dass ich WIRKLICH auf dem postbank Server lande, und nicht auf einem Fake-Server aus Rumänien, oder dass nicht jemand in meinem lokalen Netz gerade eine "Man-in-the-Middle-Attacke" macht und meine Zugangsdaten abfangen will?
Der Client Browser enthält eine ganze Reihe von vertrauenswürdigen Root CA Zertifikaten, z. B. von Verisign. JEDES Webserverzertifikat, das z. B. von Verisign SIGNIERT wurde, wird automatisch als vertrauenswürdig eingestuft, man erhält keine Fehlermeldung wenn man so eine Webseite aufruft.
Sendet der Webserver jedoch ein Zertifikat, das NICHT von einer vertrauenswürdigen Root CA signiert wurde - dann ist das Zertifikat nicht vertrauenswürdig. Es KANN sich also um eine Fälschung handeln, oder der Webserver-Admin ist ein Schlamper (meist trifft zweites zu) oder er hat keine Ahnung von der Materie.
Wenn ich keine teure Signierung von Verisign kaufen will, da ich keine Kohle habe, dann mache ich eben meine eigene Root CA. Da jedoch die Clients diese Root CA nicht kennen und ihr auch nicht vertrauen, müssen die Clients in ihren Browser das Root CA meiner eigenen CA importieren - beim Aufruf einer Webserver Webseite, die ein von meiner eigenen Root CA signiertes Webserverzertifikat anzeigt, wird dann keine Fehlermeldung erscheinen, dass das Zertifikat nicht vertrauenswürdig wäre.
[B]THX ! Werd`s mir morgen mal in ruhe durchlesen! Danke!![/B]
OK. Hab ich jetzt verstanden (hoffe ich^^)
Mal zusammengefasst: Wenn man ein gültiges Zertifikat haben will, muss man es z.B. auf Verisign kostenpflichtig machen lassen. Außer der Benutzer fügt, mein vorher selbst generiertes Zertifikat in seinen Browser als vertrauenswürdig zu.
Richtig so??
Naja das ist mir noch zu kompliziert. Ich fange erstmal mit den leichten an und in einen halben-einen Jahr wage ich mich vielleicht nochmal an das ran ;)
Aber eins möchte ich trozdem noch wissen: Wie verlängere ich jetzt mein Zertifikat, weil es ja abgelaufen anzeigt?
Danke,
Gruß Bernie.
Mal zusammengefasst: Wenn man ein gültiges Zertifikat haben will, muss man es z.B. auf Verisign kostenpflichtig machen lassen. Außer der Benutzer fügt, mein vorher selbst generiertes Zertifikat in seinen Browser als vertrauenswürdig zu.
Richtig so??
Naja das ist mir noch zu kompliziert. Ich fange erstmal mit den leichten an und in einen halben-einen Jahr wage ich mich vielleicht nochmal an das ran ;)
Aber eins möchte ich trozdem noch wissen: Wie verlängere ich jetzt mein Zertifikat, weil es ja abgelaufen anzeigt?
Danke,
Gruß Bernie.
Du kannst zu Testzwecken ja problemlos mit deinem abgelaufenen Zertifikat weitermachen! Funktioniert ja alles soweit. Um ne eigene Root CA aufzusetzen musst du ja dann auch nur ne Handvoll Befehle eintippen und die Sache ist erledigt mti der Zertifikatsverlängerung!
Welche Befehle das sind steht in obigem Link drin. Dann hast du aber immer noch das DNS Problem, da der Client auch immer überprüft ob der Servername im Zertifikat mit dem DNS Namen des Servers übereinstimmt (nslookup Namensauflösung).
Der Client importiert in seinen Browser - wenn man KEIN von Verisign oder einer anderen offiz. Root CA signiertes Zertifikat hat - das ROOT CA Zertifikat das das Webserver-zeritifikat signiert hat!
Der client prüft nämlich, wenn er von einem webserver ein zertifikat angezeigt bekommt, ob das Zertifikat von einer vertrauenswürdigen Root CA signiert wurde! Und DAMIT deine eigene Root CA als vertrauenswürdig erkannt werden KANN, muss eben das Root CA Zertifikat im Browser importiert sein! Kapische?
Letztendlich gibt es VERSCHIEDENE Zertifikate!
1. Das Root CA Zertifikat, das der Client in seinen Browser importiert damit er die Vertrauenswürdigkeit des Webserver Zertifikats prüfen kann
2. das Webserver Zeritifkat das von der Root CA signiert wurde
Schritt 1 kann man sich sparen - wenn man sein Webserver Zertifikat von Verisign signieren lässt, da das Root CA Zertifikat von Verisign bereits im Client Browser als vertrauenswürdig eingetragen bzw. importier ist! Kapische! Das ist der einzige Vorteil den so ein gekauftes Verisign Zertifikat mit sich bringt. Jeder Browser der welt wird einem von Verisign signierten Webserver Zeritifkat automatisch vertrauen.
Ja, es ist kompliziert und nicht gerade selbsterklärend. Ich denke auch dass kaum ein Benutzer eine Ahnung hat worum es geht - man vertraut halt auf das "https" und denkt "alles verschlüsselt und sicher" - das stimmt sogar, es ist verschlüsselt. Ob man jedoch wirklich mit dem server verbunden ist mit dem man verbunden sein WILL heisst das noch lange nicht. Viel zu leicht kann man einem Benutzer ein gefaktes Zertifikat unterjubeln. Und dann geht die Verschlüsselung nur bis zum Angreifer, und dieser baut mit entsprechenden Tools dann noch eine verschlüsselte Verbindung zum eigentlichen Webserver auf - der User bemerkt davon GARNIX, und der Angreifer muss nichmal ein "Crack" sein, da die Tools da alles selber machen, schneller als der User furzen kann.
Welche Befehle das sind steht in obigem Link drin. Dann hast du aber immer noch das DNS Problem, da der Client auch immer überprüft ob der Servername im Zertifikat mit dem DNS Namen des Servers übereinstimmt (nslookup Namensauflösung).
Der Client importiert in seinen Browser - wenn man KEIN von Verisign oder einer anderen offiz. Root CA signiertes Zertifikat hat - das ROOT CA Zertifikat das das Webserver-zeritifikat signiert hat!
Der client prüft nämlich, wenn er von einem webserver ein zertifikat angezeigt bekommt, ob das Zertifikat von einer vertrauenswürdigen Root CA signiert wurde! Und DAMIT deine eigene Root CA als vertrauenswürdig erkannt werden KANN, muss eben das Root CA Zertifikat im Browser importiert sein! Kapische?
Letztendlich gibt es VERSCHIEDENE Zertifikate!
1. Das Root CA Zertifikat, das der Client in seinen Browser importiert damit er die Vertrauenswürdigkeit des Webserver Zertifikats prüfen kann
2. das Webserver Zeritifkat das von der Root CA signiert wurde
Schritt 1 kann man sich sparen - wenn man sein Webserver Zertifikat von Verisign signieren lässt, da das Root CA Zertifikat von Verisign bereits im Client Browser als vertrauenswürdig eingetragen bzw. importier ist! Kapische! Das ist der einzige Vorteil den so ein gekauftes Verisign Zertifikat mit sich bringt. Jeder Browser der welt wird einem von Verisign signierten Webserver Zeritifkat automatisch vertrauen.
Ja, es ist kompliziert und nicht gerade selbsterklärend. Ich denke auch dass kaum ein Benutzer eine Ahnung hat worum es geht - man vertraut halt auf das "https" und denkt "alles verschlüsselt und sicher" - das stimmt sogar, es ist verschlüsselt. Ob man jedoch wirklich mit dem server verbunden ist mit dem man verbunden sein WILL heisst das noch lange nicht. Viel zu leicht kann man einem Benutzer ein gefaktes Zertifikat unterjubeln. Und dann geht die Verschlüsselung nur bis zum Angreifer, und dieser baut mit entsprechenden Tools dann noch eine verschlüsselte Verbindung zum eigentlichen Webserver auf - der User bemerkt davon GARNIX, und der Angreifer muss nichmal ein "Crack" sein, da die Tools da alles selber machen, schneller als der User furzen kann.
Ok. Vielen, vielen Dank für die ausführliche Erklärung! Hab`s verstanden 
Was ist wenn ich eine dyndns eintrage oder eine statitische IP hab? Dann müsste es doch funktionieren, und das Problem wäre weg?
In den Link, den du mir gegeben hast steht folgendes:
Geht es dann mit cacert.org kostenlos?? Was ist der Unterschied (zwischen VeriSign)?
Ist das der einzige Unterschied oder gibts noch mehr?
OK. Die Theorie hätte ich verstanden. Jetzt gehen wir mal zum pratischen:
Eine Root-CA einrichten:
Ich hab jetzt "openssl" geöffnet (befindet sich in C:\xampp\apache\bin) und die Befehle eingegeben, leider erscheint aber nach jeden Befehl das hier:
Screen:
http://img227.imageshack.us/img227/5214/002lo3.png
Meine Verzeichnisse sind wie folgt aufgebaut:
C:\xampp\apache liegen bin,conf,error,icons,logs,modules,proxy,symobls,apache_installservice.bat,apache_uninstallservice.bat,makecert.bat
Mit "makecert.bat" funktioniert`s übrigens auch nicht, dann kommt immer das hier:
Screen:
http://img293.imageshack.us/img293/8822/dieshv3.png
Und wenn ich dann den apache-server wieder starten will gehts nicht mehr:
Screen:
http://img293.imageshack.us/img293/5092/dassz5.png
In C:\xampp\apache\conf liegen
extra,ssl.crl,ssl.crt,ssl.csr,ssl.key,ssl.prm (alles Ordner)
Schonmal danke !
//edit: makecert.bat brauchst du vielleicht noch.
Dann hast du aber immer noch das DNS Problem, da der Client auch immer überprüft ob der Servername im Zertifikat mit dem DNS Namen des Servers .. > übereinstimmt (nslookup Namensauflösung).
Was ist wenn ich eine dyndns eintrage oder eine statitische IP hab? Dann müsste es doch funktionieren, und das Problem wäre weg?
In den Link, den du mir gegeben hast steht folgendes:
Einige CA (z.B. cacert.org) stellen signierte Zertifikate kostenlos zur Verfügung, während andere (z.B. VeriSign) jährlich eine Gebühr für die Verlängerung > ihrer Signatur verlangen.
Geht es dann mit cacert.org kostenlos?? Was ist der Unterschied (zwischen VeriSign)?
Einige Browserhersteller (z.B. Microsoft) vertrauen nur "kommerziellen" CAs. Daher müssen Nutzer des Internet-Explorers das Root-Zertifikat und die.... > CRL von https://www.cacert.org/index.php?id=3 importieren, bevor sie die Serverzertifikate der "kostenlosen" cacert.org prüfen können.
Ist das der einzige Unterschied oder gibts noch mehr?
OK. Die Theorie hätte ich verstanden. Jetzt gehen wir mal zum pratischen:
Eine Root-CA einrichten:
Ich hab jetzt "openssl" geöffnet (befindet sich in C:\xampp\apache\bin) und die Befehle eingegeben, leider erscheint aber nach jeden Befehl das hier:
Screen:
http://img227.imageshack.us/img227/5214/002lo3.png
Meine Verzeichnisse sind wie folgt aufgebaut:
C:\xampp\apache liegen bin,conf,error,icons,logs,modules,proxy,symobls,apache_installservice.bat,apache_uninstallservice.bat,makecert.bat
Mit "makecert.bat" funktioniert`s übrigens auch nicht, dann kommt immer das hier:
Screen:
http://img293.imageshack.us/img293/8822/dieshv3.png
Und wenn ich dann den apache-server wieder starten will gehts nicht mehr:
Screen:
http://img293.imageshack.us/img293/5092/dassz5.png
In C:\xampp\apache\conf liegen
extra,ssl.crl,ssl.crt,ssl.csr,ssl.key,ssl.prm (alles Ordner)
Schonmal danke !
//edit: makecert.bat brauchst du vielleicht noch.
@echo off
set OPENSSL_CONF=./bin/openssl.cnf
if not exist .\conf\ssl.crt mkdir .\conf\ssl.crt
if not exist .\conf\ssl.key mkdir .\conf\ssl.key
bin\openssl req -new -out server.csr
bin\openssl rsa -in privkey.pem -out server.key
bin\openssl x509 -in server.csr -out server.crt -req -signkey server.key -days 365
set OPENSSL_CONF=
del .rnd
del privkey.pem
del server.csr
move /y server.crt .\conf\ssl.crt
move /y server.key .\conf\ssl.key
echo.
echo -----
echo Das Zertifikat wurde erstellt.
echo The certificate was provided.
echo.
pause
set OPENSSL_CONF=./bin/openssl.cnf
if not exist .\conf\ssl.crt mkdir .\conf\ssl.crt
if not exist .\conf\ssl.key mkdir .\conf\ssl.key
bin\openssl req -new -out server.csr
bin\openssl rsa -in privkey.pem -out server.key
bin\openssl x509 -in server.csr -out server.crt -req -signkey server.key -days 365
set OPENSSL_CONF=
del .rnd
del privkey.pem
del server.csr
move /y server.crt .\conf\ssl.crt
move /y server.key .\conf\ssl.key
echo.
echo -----
echo Das Zertifikat wurde erstellt.
echo The certificate was provided.
echo.
pause
habs jetzt geschafft
man muss einfach nur makecert.bat ausführen, ein paar daten eingeben und schon ist das zertifikat 1 Jahr gültig. Das Problem mit den dns-name hat man nicht mehr, wenn man einfach eine statische adresse (z.B. eine dynamische dns ) eingibt.
der einzige fehler: Man mu7ss server.key in das verzeichnis von makecert.bat kopieren!
DANKE FÜR DEINE HILFE! Ohne dich hätte ich es nicht verstanden und hätte keine Ahnung wie das alles funktioniert. Ich werd jetzt noch ein bisschen mehr darüber lesen, das ist echt interessant wenns funktioniert.
VIELEN DANK !!
man muss einfach nur makecert.bat ausführen, ein paar daten eingeben und schon ist das zertifikat 1 Jahr gültig. Das Problem mit den dns-name hat man nicht mehr, wenn man einfach eine statische adresse (z.B. eine dynamische dns ) eingibt.
der einzige fehler: Man mu7ss server.key in das verzeichnis von makecert.bat kopieren!
DANKE FÜR DEINE HILFE! Ohne dich hätte ich es nicht verstanden und hätte keine Ahnung wie das alles funktioniert. Ich werd jetzt noch ein bisschen mehr darüber lesen, das ist echt interessant wenns funktioniert.
VIELEN DANK !!
