Hallo NG,
wir sind noch in der Testphase einer virtuellen UTM (11.4.2) und setzen uns gerade mit der Reverse-Proxy Funktionalität aus einander.
Leider ist es uns bisher nicht gelungen verschiedene (Wildcard, SAN, UC) SSL-Zertifikate von Thawte, Verisign und/oder Comodo zu importieren.
Welches Format müssen denn die echten Zertifikate (x.509) haben ?
Danach haben wir versucht unsere Stammzertifikate unserer zweistufigen CA-Infrastruktur zu importieren, leider geht dies auch nicht.
Kann man denn wenigsten die Securepoint CA als Sub-CA einer übergeordneten CA anbinden ?
Reverse-Proxy SSL-Zertifikate
Moderator: Securepoint
-
- Beiträge: 25
- Registriert: Di 12.08.2014, 20:41
Reverse-Proxy SSL-Zertifikate
MfG
Andreas Altermann
Andreas Altermann
- Christian E.
- Securepoint
- Beiträge: 238
- Registriert: Do 05.07.2012, 16:19
- Wohnort: Lüneburg
Hallo,
welche Meldung bekommen Sie wenn Sie versuchen die Zertifikate zu importieren?
Bitte beachten Sie, dass Sie in die Firewall nur PEM-encodierte Dateien importieren können. Sollte
die CRL DER-encodiert sein, müssen Sie die vorher konvertieren.
Zudem müssen Sie zunächst die CRL importieren. Diese bekommen Sie von der Zertifizierungsstelle. Entweder von deren Webseite
oder - sollten Sie OpenSSL verwenden wollen:
Im Output gibt es dann was, das nennt sich "CRL Distribution Points". Dahinter steht vermutlich eine URL,
unter der Sie die CRL herunterladen können.
Wenn Ihnen die Zertifikate als als CER-File vorliegen, können Sie diese unter Linux mit Hilfe der OpenSSL Anwendung umwandeln.
1. Stellen Sie sicher, dass OpenSSL installiert ist
2. Öffnen Sie ein Terminal und geben Sie folgenden Befehl ein:
openssl x509 -in /pfad/certificate.cer -outform pem -out /pfad/certificate.pem
Unter Windows wiederrum gibt es mehrere Programme zur Umwandlung z.B. die "Win32 OpenSSL" Anwendung.
1. Eingabeaufforderung starten
2. In den \bin\ Ordner des OpenSSL Installationsverzeichnis wechseln
3. openssl x509 -in C:\pfad\certificate.cer -outform pem -out C:\pfad\certificate.pem
Gruß
welche Meldung bekommen Sie wenn Sie versuchen die Zertifikate zu importieren?
Bitte beachten Sie, dass Sie in die Firewall nur PEM-encodierte Dateien importieren können. Sollte
die CRL DER-encodiert sein, müssen Sie die vorher konvertieren.
Zudem müssen Sie zunächst die CRL importieren. Diese bekommen Sie von der Zertifizierungsstelle. Entweder von deren Webseite
oder - sollten Sie OpenSSL verwenden wollen:
Code: Alles auswählen
# openssl x509 -in <CA-FILE> -noout -text
unter der Sie die CRL herunterladen können.
Wenn Ihnen die Zertifikate als als CER-File vorliegen, können Sie diese unter Linux mit Hilfe der OpenSSL Anwendung umwandeln.
1. Stellen Sie sicher, dass OpenSSL installiert ist
2. Öffnen Sie ein Terminal und geben Sie folgenden Befehl ein:
openssl x509 -in /pfad/certificate.cer -outform pem -out /pfad/certificate.pem
Unter Windows wiederrum gibt es mehrere Programme zur Umwandlung z.B. die "Win32 OpenSSL" Anwendung.
1. Eingabeaufforderung starten
2. In den \bin\ Ordner des OpenSSL Installationsverzeichnis wechseln
3. openssl x509 -in C:\pfad\certificate.cer -outform pem -out C:\pfad\certificate.pem
Gruß
-
- Beiträge: 25
- Registriert: Di 12.08.2014, 20:41
Hallo Christian,
vielen Dank für die Antwort. Zwischenzeitl. haben wir wegen der Komplexität in unseren Fall bzw. unseren Wünschen es mit dem Support direkt geklärt.
Ich werde hierzu noch die Lösung posten.
vielen Dank für die Antwort. Zwischenzeitl. haben wir wegen der Komplexität in unseren Fall bzw. unseren Wünschen es mit dem Support direkt geklärt.
Ich werde hierzu noch die Lösung posten.
MfG
Andreas Altermann
Andreas Altermann
-
- Beiträge: 25
- Registriert: Di 12.08.2014, 20:41
So, wie versprochen anbei der Link (Doku) wie wir es jetzt umgesetzt haben.
ftp://ftp.alfru.net/help/ssl_securepoint.pdf
ftp://ftp.alfru.net/help/ssl_securepoint.pdf
MfG
Andreas Altermann
Andreas Altermann
Klasse Dokumentation!
Die Sache mit den CRLs hatte ich hier schon mal angesprochen.
http://support.securepoint.de/viewtopic.php?f=31&t=5877
Es geht, aber unter Umständen nicht richtig oder nicht schön.
Mir ist sowieso nicht ganz klar, warum der "Server" sein eigenes Zertifikat nochmal anhand einer CRL überprüfen muss. Das ist doch eigentlich nur für den Client (Browser, E-Mail-Client etc.) interessant. Denn der möchte doch die Identität des Servers bestätigt bekommen. Der Server sollte eigentlich wissen wer er ist.
Aber die Sache hat sicher historische Gründe...
Die Sache mit den CRLs hatte ich hier schon mal angesprochen.
http://support.securepoint.de/viewtopic.php?f=31&t=5877
Es geht, aber unter Umständen nicht richtig oder nicht schön.
Mir ist sowieso nicht ganz klar, warum der "Server" sein eigenes Zertifikat nochmal anhand einer CRL überprüfen muss. Das ist doch eigentlich nur für den Client (Browser, E-Mail-Client etc.) interessant. Denn der möchte doch die Identität des Servers bestätigt bekommen. Der Server sollte eigentlich wissen wer er ist.
Aber die Sache hat sicher historische Gründe...
-
- Beiträge: 25
- Registriert: Di 12.08.2014, 20:41
Hi Franz,
Dein Kommentar zu den CRLs ist aus meiner Sicht korrekt. Eigentl. müsste -wenn überhaupt- das Zertifikat von der UTM gegen die CRL geprüft werden, egal wo sie im Netz (http/ocsp)) liegt bzw. liegen sollte und nicht unbedingt lokal. Aber das hängt wohl bei Securepoint historisch daran, das unter "CA" eigentl. nur die eine eigene PKI (CA) mit der dazugehörigen CRL gemeint ist (entwicklungstechnisch). Aber es ist zumindest ein großer Schritt in die richtige Richtung und mal sehen was die Zukunft uns bei SP bringt. :-)
Dein Kommentar zu den CRLs ist aus meiner Sicht korrekt. Eigentl. müsste -wenn überhaupt- das Zertifikat von der UTM gegen die CRL geprüft werden, egal wo sie im Netz (http/ocsp)) liegt bzw. liegen sollte und nicht unbedingt lokal. Aber das hängt wohl bei Securepoint historisch daran, das unter "CA" eigentl. nur die eine eigene PKI (CA) mit der dazugehörigen CRL gemeint ist (entwicklungstechnisch). Aber es ist zumindest ein großer Schritt in die richtige Richtung und mal sehen was die Zukunft uns bei SP bringt. :-)
MfG
Andreas Altermann
Andreas Altermann