Wildcard SSL Zertifikat mit OpenSSL erstellen
Mit Wildcard Zertifikaten kann man beliebig viele Subdomains unterhalb einer Domain mit nur einem Zertifikat erstellen. Dies ist besonders praktisch, wenn man mehrere Dienste unter einer Domain anbietet und somit typische Domains wie www.domain.tld, ftp.domain.tld oder mail.domain.tld besitzt.
Um ein solches selbstsigniertes Zertifikat mit OpenSSL mit einer Gültigkeitsdauer von einem Jahr für die Subdomains von domain.tld zu erstellen, geht man wie folgt vor:
openssl req -new -x509 -keyout cert.pem -out cert.pem -days 365 -nodes
Country Name (2 letter code) [AU]:DE State or Province Name (full name) [Some-State]:Germany Locality Name (eg, city) []:meineStadt Organization Name (eg, company) [Internet Widgits Pty Ltd]:Firma Organizational Unit Name (eg, section) []:Abteilung Common Name (eg, YOUR name) []:*.domain.tld Email Address []:webmaster@domain.tld
Man erhält die Datei cert.pem, die das soeben erzeugte Zertifikat enthält. Dieses kann man nun problemlos in verschiedensten Programmen für alle Subdomains unterhalb von domain.tld nutzen.
Links:
TLS/SSL bei Wikipedia
Related posts:
- Debugging von SSL-Zertifikaten SSL kann zur Verschlüsselung verschiedenster Protokolle genutzt werden. Neben dem bekannten HTTPS gibt es u.a....
- adminlife.net – We care for your security! Vielleicht ist es dem einen oder anderen schon aufgefallen: Hier im Blog kann man nun...
- Gratis Virtual Machine für den VMware Player Seit Längerem gibt es schon den hervorragenden VMware Player gratis für die meisten Betriebssysteme....
- LPIC-2 Vor ein paar Tagen ist mein LPIC-2 Zertifikat eingetrudelt. Im Gegensatz zum LPIC-1 Zertifikat...
- Domainanbieter mit kompletter DNS Verwaltung Für meine drei neuen Domains adminlife.(de|net|org) war ich vor Kurzem auf der Suche nach einem...
JP Mens
Das mag funktionnieren, aber wenn ich mich recht entsinne, erlaubt RFC 2459 keine wildcards im Distinguished Name (DN) eines Zertifikates sondern lediglich im subjaltName. Der CN eines Zertifikates sollte somit gleich hostname sein und subjaltName kann demnach “DNS:*.domain.tld” enthalten.
matthias
Soweit ich weiß wäre dies dann der DN:
C=”DE”, O=”Firma”, OU=”Abteilung”, CN=”*.domain.tld”
Er setzt sich also u.a. aus dem Common Name zusammen, den ich hier ja mit *.domain.tld angegeben habe. Müsste doch also soweit richtig sein, es sei denn ich kann den DN getrennt vom CN definieren. Da steh ich nur leider auf dem Schluch, wie das in diesem Fall geht. :/
JP Mens
Wenn wildcards im DN nicht zulaessig sind, CN aber Teil des DN ist und wildcards enthaelt, dann ist das Ergebnis doch nicht zulaessig, oder?
matthias
Hmm, eigentlich nicht. Aber seltsamerweise wird es ja auch von den großen CAs vermarktet und die müssen dann ja auch gegen die RFCs handeln.
Funktionieren tut es trotzdem bei allen halbwegs modernen Browsern. Aber wenn etwas gegen die RFCs verstößt, ist das natürlich nie wirklich schön…
Tobi
Mal ne blöde Frage:
Müsste das Zertifikat nicht noch von der CA, und auch wenns die eigene ist, signiert werden?
matthias
Die CA sagt ja “nur” aus, dass DU wirklich DU bist bzw. die Domain auch wirklich die Domain ist. Aus diesem Grund ist die reine technische Funktion (=Verschlüsselung) auch ohne CA gegeben.
Tobi
Das passiert wenn man immer nur streng nach Handbuch arbeitet ohne sich zu fragen was man eigentlich tut.
Aber spätestens wenn nach der Verschlüsselung auch die Authentifizierung per SSL erfolgen soll dürfte es doch Probleme geben, oder?
matthias
Da es selbstsigniert ist, findet ja auch keine weitere Prüfung statt – bis auf die “Warnung” die du bekommst bei deinem Browser, dass es ein selbstsigniertes Zertifikat ist und der Browser nicht weiß, ob er dem Aussteller trauen kann.
Die Browser haben ja alle eine bestimmte Anzahl von Root-CA-Zertifikaten “installiert”, denen sie dann automatisch trauen. Findet man im Firefox z.B. unter “Einstellungen -> Erweitert -> Zertifikate anzeigen -> Zertifizierungsstellen”.
BTW: adminlife.net ist jetzt auch verschlüsselt mit einem *echten* Zertifikat (von einer CA signiert).
Der Adminblogger
> Da es selbstsigniert ist, findet ja auch keine weitere Prüfung
> statt – bis auf die “Warnung†die du bekommst bei deinem
> Browser, dass es ein selbstsigniertes Zertifikat ist und der
> Browser nicht weiß, ob er dem Aussteller trauen kann.
Deshalb erstellt man für sich ja auch eine ROOT-CA mit der man alle seine Zertifikate signiert (SMTPS, HTTPS, POP3S, FTPS, …) und importiert das ROOT-CA in seine Clients (Thunderbird, Firefox, lftp, …).
Fortan gehts dann auch ohne Fehlermeldung, selbst wenn das 10 Jahre gültige Zertifikat mal ablaufen und ersetzt werden sollte
Gruß,
Marcel (der mit der eigenen CA
matthias
Genau, das geht natürlich auch. Ich bin aber da immer ein bisschen faul und klicke lieber einmal in meinen Clients auf “Immer akzeptieren” anstatt überall das ROOT-CA einzuspielen
Aber Recht hast du natürlich!
Zen
Endlich jemand, der erklärt, dass es tatsächlich *.example.com (!) und nicht example.com im Common Name Schritt sein muss… Danke!
Stefan
Kann man dies noch weiter aufbohren oder lässt sich die IP eines Root-Servers statt der Domain angeben?
Wir haben derzeit das “Problem”, dass wir viele Domains auf einem Root-Server hosten, aber nicht für jede Domain ein komplettes Set (CA, Cert, …) erstellen wollen.
matthias
@Stefan
Es kann nur einen SSL verschlüsselten VHost pro IP geben (der Host Eintrag im HTTP-Header wird erst nach der Verschlüsselung vom Webserver ausgewertet). Somit würde dein Vorkommen schon hier scheitern. Abhilfe könnte evtl. ein neues Apache Modul, mit dem auch mehrere VHosts möglich sind, bringen.
Ob es möglich ist ein solches Wildcard Zertifikat zu erstellen, kann ich dir nicht mit Sicherheit sagen. Aber du könntest mal probieren ein selbst signiertes Wildcard Zertifikat mit * als Common Name zu erstellen.
Stefan
Hi Matze,
ich wollte eben nur sagen, dass das nicht ich, dein Co-Autor, ist!
matthias
Stefan, das war mir wohl bewusst