Frage zu SSL Zertifikat

D

Domi

Member
Hallo Leute, ich habe mal eine kleine Frage an Euch...
Auf unserer Firmeninternetseite markiert der Google Chrome das Schloss (welches auf eine SSL geschützte Seite hinweist) mit einem gelben Ausrufezeichen. Dabei wird erwähnt das unsere Seite eine Schwache Konfiguration (SHA-1) verwendet.

In den nächsten Tagen ist ein Teamgespräch und ich möchte dann gerne ein GeoTrust True BusinessID SAN EV Zertifikat besorgen. Für den Fall das Chef dieses Vorhaben allerdings abwinkt, wüsste ich gerne ob mir jemand sagen kann was ich in der Apache Config oder beim SSL Zertifikat übersehen haben könnte bezüglich dieser Meldung :o

Vielleicht kann mir da jemand etwas zu sagen.
Gruß, Domi

p.s. Das erwähnte GeoTrust True BusinessID SAN EV ist doch wegen seiner SAN Fähigkeit für mehrere (laut Beschreibung bis zu 25) Domains gültig, oder?
 
Mit der Apache-Konfig hat das nichts zu tun, wenn ein Zertifikat vom Aussteller mit SHA1 signiert ist.
Die aktuellen Zertifikate der Anbieter sind mit SHA256 von den Ausstellern signiert.
Zudem ist das von dir ausgesuchte auch ein Extended Validation Certificate.
Das ergibt dann ein grünes Schloss.
 
Auf unserer Firmeninternetseite markiert der Google Chrome das Schloss (welches auf eine SSL geschützte Seite hinweist) mit einem gelben Ausrufezeiche
Click to expand...
Eure Seite verwendet ein Zertifikat von Startcom welche bereits seit Jahren SHA2-Zertifkate unterstützen und auch empfehlen. Google hat auch schon länger darauf hingewiesen dass SHA1 deprecated wird. Hier handelt es sich also ausschliesslich um einen Konfigurationsfehler auf Seite der zuständigen Person bei euch. Entweder im Interface oder per CSR wurde halt SHA1 ausgewählt. Allerdings ist das bei Weitem nicht das einzige Problem an eurer SSL-Konfiguration, bitte unbedingt die Kritikpunkte auf folgender Seite abarbeiten: https://www.ssllabs.com/ssltest/analyze.html?d=secure-travel.de

In den nächsten Tagen ist ein Teamgespräch und ich möchte dann gerne ein GeoTrust True BusinessID SAN EV Zertifikat besorgen.
Click to expand...
Der grüne Balken eines EV Zertifikates kann eventuell vorteilhaft sein, ansonsten bringt dir das rund 2.5x teurere Zertifikat verglichen mit einer Startcom-Mitgliedschaft keine direkten Vorteile.

p.s. Das erwähnte GeoTrust True BusinessID SAN EV ist doch wegen seiner SAN Fähigkeit für mehrere (laut Beschreibung bis zu 25) Domains gültig, oder?
Click to expand...
Genau. SAN ist allerdings nicht Wildcard (alle Subdomains) wie das aktuelle Zertifikat welche alle Subdomains der folgenden Domains abdeckt:
*.i-m-h.de *.i-m-h.net *.reiseschutz-plus.com *.secure-travel.de
Je nachdem ob das benötigt wird brauchst du also weiterhin noch zusätzlich ein non-ev Wildcard-Zertifikat.
 
Ah.. Verdammt.. dann habe ich den Fehler gemacht, als ich das Zertifikat erstellt habe :eek:

Was die Wildcard Geschichte angeht, es muss ja nicht zwingend eine Wildcard sein. Wenn ich z.B. mail.i-m-h.de (für Mails) und dann mit und ohne WWW für secure-travel.de oder Reiseschutz Plus verwenden kann, sollte das schon ausreichen.

Das aktuelle Zertifikat habe ich (auch wenn man es nicht macht) über meinen persönlichen Account bei Startcom erstellt, darum ist auch mein Name darin. Wenn ich nun ein EV Zertifikat (wegen dem grünen Balken) bei Startcom erstellen lassen will, würde ich einen separaten Account dafür erstellen damit das getrennt ist.

d4f said:
Der grüne Balken eines EV Zertifikates kann eventuell vorteilhaft sein, ansonsten bringt dir das rund 2.5x teurere Zertifikat verglichen mit einer Startcom-Mitgliedschaft keine direkten Vorteile.
Click to expand...
Verstehe ich dich denn richtig das es keinen Unterschied macht ob ich das EV Zertifikat von gogetssl.com oder von Startcom erstellen lasse, außer dass das von Startcom um einiges günstiger ist?! :)

Gruß, Domi

Nachtrag: @GwenDragon, dein Post ist eben untergegangen.. Ja, dass EV Zertifikat mit dem grünen Schloss möchte ich schon ganz gerne auf unserer Seite haben. Und zum Zertifikat selbst.. wie in meinem Text erwähnt, dass habe ich wohl verschlampt.
 
Last edited by a moderator:
Was die Wildcard Geschichte angeht, es muss ja nicht zwingend eine Wildcard sein. Wenn ich z.B. mail.i-m-h.de (für Mails) und dann mit und ohne WWW für secure-travel.de oder Reiseschutz Plus verwenden kann, sollte das schon ausreichen.
Click to expand...
Das hängt von den Anforderungen ab :D

Ah.. Verdammt.. dann habe ich den Fehler gemacht, als ich das Zertifikat erstellt habe
Click to expand...
Im Bedarfsfall: pro Validierungsperiode kann / konnte man bei Startssl 1 Zertifikat revoken lassen und danach neu ausstellen.

Verstehe ich dich denn richtig das es keinen Unterschied macht ob ich das EV Zertifikat von gogetssl.com oder von Startcom erstellen lasse
Click to expand...
Ja und nein. Zum einen ist gogetssl keine Zertifierungsstelle sondern ein Reseller. Das ist insoweit relevant als dass zumal bei "grüner Balken" der Name einiger Stellen für technisch versierte Anwender deutlich vertrauenswürdiger ist als andere, du also hier noch wählen darfst und musst welche CA du überhaupt nimmst und leisten willst. Vorteil von Startssl ist allerdings dass du binnen dem Jahr Zertifierung weitere EV für "nur" 49$ generieren kannst.
Die Zertifierungsprozedur ist allerdings mit 59.90 + 140 USD pro Jahr nicht unbedingt günstig. Details: https://www.startssl.com/?app=40
 
Also die Anforderungen der Kollegen sind gar nicht so enorm hoch. Ich war halt nur derjenige der solch ein Zertifikat erstellt hat (SAN + Wildcard) um auf dem Server nur ein Zertifikat hinterlegen zu müssen :)

Die Funktion für einen Zertifikat revoke hatte ich schon mal gefunden, ich schaue mir das dann mal genauer an aber das sollte kein Problem und machbar sein :)

Was diese Gebühren in Höhe von $59,90 die man bei Startssl bezahlt ist ja die kleine die man sowieso braucht. Zumindest hab ich das ja bezahlt um meine Person zu identifizieren. Dafür hatten sie mich ja auch angerufen und kurz mit mir telefoniert ;) Das gogetssl ein Reseller ist, ist mir kurz nach dem Post auch wieder eingefallen... ich hatte die URL als Lesezeichen hinterlegt und mir ist dann eingefallen das ich ja mal nach Reseller geschaut hatte.

der Name einiger Stellen für technisch versierte Anwender deutlich vertrauenswürdiger ist als andere, du also hier noch wählen darfst und musst welche CA du überhaupt nimmst und leisten willst.
Click to expand...
Ich hoffe den Satz verstehe ich richtig... da die EV Zertifikate vertrauenswürdiger sind, wollte ich dieses haben. Wenn ich auf der Seite der Sparkasse gucke, gibt es einem ein besseres / sicheres Gefühl :) Wo ich allerdings harke ist der Teil mit dem "wählen" des CA, wie ist das genau gemeint? Da stehe ich blöderweise gerade auf dem Schlauch :eek:

Gruß, Domi
 
Wenn ich einen Tipp zu StartSSL geben darf:
Revoken ist nicht notwendig.
Es reicht, wenn das neue Zertifikat auf andere Subdomains lautet, was bei Wildcard Certs sowieso irrelevant ist.

Beispiel:
es wurde aus Versehen *.example.com SHA1 erzeugt.
Eigentlich benötigt man aber SHA2.

Jetzt reicht es aus, wenn man ein neues Zertifikat erzeugt mit (z.B.) test.example.com und *.example.com

Den Tipp hatte ich aus dem StartSSL Forum und ihn auch schon mal genutzt.
 
Ach stimmt, ganz vergessen. Da kann ich Orebor nur zustimmen dass es funktioniert. Wurde mir mal so sogar vom StartSSL CEO vorgeschlagen als ich ein Zertifikat wegen Fehler revoken lassen wollte.
 
Okay, dass wäre auch eine Variante... Ich glaube vor ein paar Jahren hatte ich das auch mal für eine von meinen privaten Domains so gemacht.

Da ich die Grundbausteine über ein Linuxsystem erstelle, brauche ich doch nur ein neue CA erstellen und dann einen Key mit dem Parameter '-sha256' erstellen, oder irre ich mich da gerade? Die nächste Frage wäre dann noch, kann man noch eine Nummer sicherer gehen bei Zertifikaten für Webseiten, oder ist der SHA-256 da die bessere Wahl?!

Wenn ich mich jetzt nicht irre, kennt SQL oder PHP auch SHA-512 :D Ist aber die Frage ob das Sinn macht oder eben nicht und ob es funktioniert ;)

Gruß, Domi
 
Aktuelle SSL-Zertifikate sollten nicht mehr mit SHA-1 sondern mit einem aus der Familie SHA-2 signiert werden. Mit SHA256 passt das.

Wie du das einstellen musst, hängt von deinem Programm, welches die Zertifikatsanforderung erzeugt, ab.
 
Hallöchen, leider komme ich jetzt erst dazu, einiges zu erzählen. Also mein CA und die KEY Files habe ich unter Linux immer ganz einfach mit 'openssl' erstellt.

Ich glaube unter Windows gibt es da auch etwas, aber da hab ich keine Ahnung wie das funktioniert, daher bevorzuge ich die Variante über Linux.. das kann ich wenigstens und da ich solche Systeme administriere, geht das für mich einfacher als wenn ich einem der Windows Clients so etwas beibringen muss :)

Aber bevor ich die neuen SSL Zertifikate erstelle, werde ich wohl erst einmal bei Startssl die Identifizierung als Firma durchführen um das EV Zertifikat erstellen zu können... dann hätte ich gleich ein neues SHA2 Zertifikat mit der erweiterten Validierung :)

Gruß, Domi
 
Hallo Leute, ich habe mal eine kleine Frage zum erstellen des neuen Zertifikates... Reichen folgende Parameter für ein neues und sicheres Zertifikat aus?
Code: 
openssl req -nodes -newkey rsa:4096 -sha256 -keyout domain.key -out domain.csr

Ich denke mal 4096bit dürfte mehr als ausreichend sein :D Und durch den sha256 sollte es auch passen... oder geht noch eine Nummer sicherer die auch auf allen Browser kompatibel ist?!

Gruß, Domi
 
So wäre es heutzutage richtig:
Code: 
### Zufälliges, sicheres Passwort für das Zertifikat
### erzeugen und zur späteren (automatisierten)
### Verwendung in der .pwd speichern.
openssl rand -hex 16 | \
    openssl passwd -1 -stdin | \
    tr -cd '[[:alnum:]]' | \
    sed -e 's/^1//' \
    > private/srv.example.org.pwd

### Privaten Schlüssel (RSA mit 4096 Bit Länge
### und AES256 verschlüsselt) zum Signieren
### des Zertifikats erzeugen.
openssl genpkey \
    -aes-256-cbc \
    -algorithm RSA \
    -pkeyopt 'rsa_keygen_bits:4096' \
    -out private/srv.example.org.key.enc \
    -pass file:private/srv.example.org.pwd

### Zertifikatsanforderung erzeugen und
### mit dem privaten Schlüssel signieren.
openssl req \
    -new \
    -sha256 \
    -out certs/srv.example.org.csr \
    -key private/srv.example.org.key.enc \
    -passin file:private/srv.example.org.pwd

### Eine passwortlose Kopie des privaten Schlüssels anlegen,
### wie sie zum problemlosen Starten von Diensten wie
### Webserver, Mailserver, etc benötigt wird.
openssl pkey \
    -in private/srv.example.org.key.enc \
    -out private/srv.example.org.key \
    -passin file:private/srv.example.org.pwd
 
Hallo Joe User, vielen dank für dein Skript und den Kommentaren :)
Kurz zur Aufklärung, damit ich jetzt nichts falsch verstehe.
1. Ein zufälliges Kennwort erstellen
2. Das Key File (Privater Schlüssel) erstellen, verschlüsseln und mit Zufallskennwort versehen
3. Das csr File erstellen, welches ich an startssl.com weiter reiche um mein crt zu generieren
4. Das Key File (Privater Schlüssel) erstellen (ohne Verschlüsselung oder Kennwort) was anschließend für meine Dienste (Apache etc.) ist

Ist das Korrekt? Ich frage nur aus Neugierde für was das verschlüsselte Key File erstellt wird wenn das unverschlüsselte auf dem Server liegt. Ich würde sonst auf das Password File und den verschlüsselten privaten Key verzichten, beuge mich dem ganzen aber gerne und übernehme das so, wenn ich den genauen Hintergrund verstehe :)

Gruß, Domi
 
Das Passwort fürs Keyfile sollte man immer setzen, schliesslich weiss man nie, ob man es vielleicht doch mal benötigt, zum Beispiel weil ein relevanter (Sec-)Bug in OpenSSL oder einem Dienst (fehlerhafte Verarbeitung, etc) auftritt, oder neue Vorschriften (RFC, Gesetz, Richtlinie, CA-Policy) in Kraft tritt und man dann das Passwort statt dem Keyfile hinterlegen muss.
Man erspart sich dann das (teure) erneuern seiner Zertifikate.

Nur als Beispiel, warum ein Passwort immer Sinn macht, auch wenn man es aktuell nicht zu benötigen glaubt.

Lieber mit Passwort als ohne ;)
 
Sorry Joe, aber Deine Erläuterung warum man - obwohl man den Private-Key ohne Kennwortschutz am Server liegen hat zusätzlich den Private-Key mit einem Secret geschützt aufheben sollte ist für mich nicht nachvollziehbar.

Ich kann mit einem OpenSSL-Einzeiler jederzeit den Kennwortschutz entfernen, hinzufügen oder das Kennwort wechseln. Das ändert selbstverständlich überhaupt nichts am Zertifikat oder dessen gültigkeit, solange das Schlüsselpaar unverändert bleibt.
 
Die Frage nach der Verschlüsselung/PW-Schutz des Keyfiles hatte ich mir auch schon gestellt. Im Sinne eines Backups bzw. zu Zwecken der Hinterlegung für den Fall der Wiederherstellung ist das vom Handling praktischer. Zumindest organisatorisch könnte man sicherstellen, dass das unverschlüsselte und damit ungeschützte Keyfile niemals den Server verlässt.
 
You must log in or register to reply here.
Back
Top