# [nginx] HTTP --> HTTPS Rewrite - Ich will SSL :)



## FirstS0ul (8. Juni 2015)

Moin zusammen,

ich möchte meinen Server auf SSL umstellen. Das betrifft logischerweise nur die Webdienste.
Sicherheit schadet nie. Besonders wenn man eine Cloud und WebMail Dienste hat 

Ich habe einen vServer mit zwei Domains.
Ich würde gern beide Domains mit SSL Zertifikaten ausstatten.
Wie das funktioniert konnte ich über das ISPConfig Handbuch herausfinden. Ein selbsterstelltes Zertifkat klappt schonmal.
Jetzt würde ich gern jeden HTTP Request auf HTTPS umleiten, so das die Benutzer immer auf die verschlüsselte Umgebung kommen.

Wie kann ich das lösen?

PS: Ich würde für den anfang mir ein kostenloses Zertifikat bei startssl besorgen. Oder kennt ihr günstige (bessere) alternativen.


----------



## robotto7831a (8. Juni 2015)

In ISPConfig in den nginx Direktiven folgendes eintragen.



> if ($scheme != "https") {
> rewrite ^ https://www.meineurl.tld$request_uri? permanent;
> }


----------



## FirstS0ul (8. Juni 2015)

ok danke!
Ich gehen davon aus, dass ich das auch bei jeder Subdomain eintragen muss?
also z.B:

```
if ($scheme != "https") {
rewrite ^ https://cloud.meineurl.tld$request_uri? permanent;
}
```


----------



## robotto7831a (8. Juni 2015)

Ja.


----------



## FirstS0ul (8. Juni 2015)

fein! Danke! Dann mache ich mich mal ans Werk. Ist ja eig. nur fleißarbeit


----------



## FirstS0ul (8. Juni 2015)

Info für alle:
startssl ist zwar ganz nett, aber leider nur für eine Domain. Subdomains laufen wieder nicht damit. Schade.


----------



## robotto7831a (8. Juni 2015)

Klar was hast Du denn gedacht?

Wildcard SSL Zertifikate kosten.

Kannst ja mal https://buy.wosign.com/free/ probieren. Eine Domain habe ich schon damit getestet aber mehrere noch nicht.


----------



## nowayback (8. Juni 2015)

Zitat von FirstS0ul:


> Info für alle:
> startssl ist zwar ganz nett, aber leider nur für eine Domain. Subdomains laufen wieder nicht damit. Schade.


doch mit class 2 validierung



Zitat von robotto7831a:


> Wildcard SSL Zertifikate kosten.


Das ist nicht korrekt. Du zahlst nur die Validierung für Class 2 (59,90$) und kannst danach soviele Wildcardzertifikate und Subdomainzertifikate beantragen wie du willst, solang die Domains dir gehören - und zwar alle gratis - für die Dauer von einem Jahr


----------



## FirstS0ul (8. Juni 2015)

Zitat von nowayback:


> doch mit class 2 validierung
> 
> 
> Das ist nicht korrekt. Du zahlst nur die Validierung für Class 2 (59,90$) und kannst danach soviele Wildcardzertifikate und Subdomainzertifikate beantragen wie du willst, solang die Domains dir gehören - und zwar alle gratis - für die Dauer von einem Jahr


Sogar für 2 Jahre. Das ist der große Vorteil und das Angebot werde ich wohl warnehmen.
Du zahlt per Vaildation und das ist alle 2 Jahre


----------



## nowayback (8. Juni 2015)

Zitat von FirstS0ul:


> Sogar für 2 Jahre. Das ist der große Vorteil und das Angebot werde ich wohl warnehmen.
> Du zahlt per Vaildation und das ist alle 2 Jahre


Wieder nicht korrekt. Es war schon Absicht von mir, wie ich das geschrieben hatte... aber ich erklär es dir gerne im Detail:
Du machst die Class 2 Validierung und kannst dir damit Zertifikate erstellen, die 2 Jahre gültig sind. Du kannst dir aber die Zertifikate nur bis zu 350 Tage nach der Validierung erstellen. Solltest du danach ein weiteres Wildcard oder Subdomainzertifikat benötigen, musst du dich erneut validieren. Für einfache Domains kannst du aber trotzdem problemlos ein Class 1 Zertifikat erstellen - wie gehabt.


----------



## FirstS0ul (8. Juni 2015)

öhm okay. Wo steht das?
das steht "per vaildation". Dann verstehe ich das die Class2 Validierung 2 Jahre hält...


----------



## nowayback (8. Juni 2015)

musste ich jetzt selbst erstmal raussuchen... https://www.startssl.com/?app=2



> StartSSL™ identity and organization validation are available for only US $ 59.90 each, where organization validation implies prior identity validation. Once validated, certificates are freely available through the advanced StartSSL™ Control Panel and unlimited for 350 days of the validated identity/organization.


----------



## FirstS0ul (8. Juni 2015)

Achso. Okay. Danke. Würde aber für mich reichen. Da in nächster Zeit keine neuen Domains dazukommen. Es bleibt bei den beidne Maindomains. Ich erstelle ja ein Wildcard Zertifikat so kann ich alle Subdomains abdecken, da ich ja nicht für jede Domain ein Zertifikat anlege.


----------



## nowayback (8. Juni 2015)

das ist korrekt... dann kann ich dir nur raten nach 349 Tagen alle Zertifikate neu zu erstellen, so kannst du mit 1x Validierung Zertifikate mit insgesamt 2 Jahre + 349 Tage nutzen


----------



## FirstS0ul (8. Juni 2015)

Uhh netter Trick  Knapp 3 Jahre für knapp 55€ ist ok ^^


----------



## nowayback (8. Juni 2015)

ja... der Trick ist dann (nach 349 Tagen oder wann auch immer du die erneuern willst) bei den wildcarddomains dann erst eine subdomain anzugeben und danach *. sonst müsstest du das "alte" erst zurückziehen und das kostet rund 25$ pro Zertifikat.
Diese Vorgehensweise stammt im Übrigen vom CA Master mit dem ich wegen ähnlichen Dingen in Kontakt stand.


----------



## JeGr (9. Juni 2015)

Um kurz noch hier anzusetzen: Man kann bei StartSSL somit mit einer Class2 Validation *nicht nur *ein Wildcard Zertifikat erstellen, sondern auch ein *SAN/Wildcard* Zertifikat. Da StartSSL auf CSRs keinen großen Wert legt, sondern das in der WebGUI anlegen lässt, was du im Zertifikat haben willst, ist es sogar möglich bspw. solch ein Zertifikat zu erstellen:

*.domain.de, domain.de, *.sub.domain.de, *.domain2.de, domain2.de, *.dev.domain2.de, ...

Gerade wenn man einen einzigen Server mit mannigfaltigen eigenen Domains hat (die ja heute recht billig sind), und hier bspw. für Dev (sub-)Domains gleich mal vorsorgen möchte, ist das sehr schick.  Und gerade SAN Zertifikate, also Zerts mit mehreren unterschiedlichen Domains im Zertifikat sind sonst sehr teuer.

Auch *sehr praktisch nutzbar *für bspw. das ISPConfig3 Feature *"Website auto alias":*

ISPConfig Server #1 bspw. hört auf: _isp01.domain.net_
ISPConfig Server #2 hört auf: _isp02.domain.net_
MX wird definiert als _mta01/02.domain.net_
DNS wird übernommen als _dns01/02.domain.net_
Eigentliche Webseite: _www.domain.de_ (Abtrennung von .net für Serverdienste und .de für das eigentliche "Business")
Zusätzliche Webseite: _www.domain2.de_
*AutoAlias *Feature von ISPC3 für Hosting Kunden: _c[client_id]w[website_id].alias.domain.net
_
Durch einbacken von: 
_domain.net, *.domain.net, *.alias.domain.net, *.domain.de, domain.de, *.domain2.de, domain2.de _
hat man mit einer Ausgabe von 59$ ein Zertifikat, was alle Ansprüche abdeckt und man kann seine Dienstleistungen ordentlich aufziehen und separieren ohne auf SSL verzichten zu müssen. Pluspunkt: Die diversen Services von ISPConfig können dann auf Linux Ebene alle via Symlinks auf das gleiche Zertifikatspaket zeigen (Postfix, Dovecot, Courier, FTP, was immer ihr installiert habt) und wenn ihr das mal aktualisieren müsst, ist es gleich für alle Dienste wieder auf dem neuen Stand.

Grüße
-jens


----------



## FirstS0ul (10. Juni 2015)

Wow. Danke für den Tipp, dann lohnt sich das ja echt.

Ich nutze ISPConfig für mich auch nur als einfaches Werkzeug. Ich habe keine Kunden etc. ich verwalte nur zwei Webseiten die darauf laufen  Also brauche ich "so einen Aufwand" wie du beschrieben hast nicht


----------



## JeGr (10. Juni 2015)

> Also brauche ich "so einen Aufwand" wie du beschrieben hast nicht 
Na klar, dann ist das natürlich weniger Aufwand, allerdings kann man auch für seine eigene Infrastruktur bestimmte Dinge gleich trennen oder ordentlich separieren, damit man damit wengier Ärger hat. Und wer weiß ob das nicht später doch mal größer wird und wächst. Aber gerade bspw. der konfigurierbare auto-alias ist ein nettes Feature wenn man einen Webspace schon einmal vorbereiten möchte, ohne dass man bereits eine Domain dafür in Planung hat. Und wenn man dann bereits ein passendes Wildcard Zertifikat am Start hat, dass diese Domain mit abdeckt - umso besser


----------



## FirstS0ul (11. Juni 2015)

Ich habe nun mein Zertifikat... Scheinbar klappt das leider nicht mit dem Code...
Er will einfach nicht auf HTTPS umleiten.

Andere Tipps?


----------



## JeGr (11. Juni 2015)

Dann hast du da am VHost ein anderes Problem, der Redirect Code ist defintiv richtig.


----------



## FirstS0ul (11. Juni 2015)

Komisch..
Das Problem ist auch, wenn ich in der Domain 
den Code hinterlege und ich eine Subdomain habe, die auf ein Unterverzeichnis leitet, dann funktioniert der Redirect. Dummerweise nicht in das Unterverzeichnis, sondern in den Root der Domain.


----------



## JeGr (11. Juni 2015)

Kannst du das ggf. näher beschreiben? Das klingt irgendwie konfus  Gehts anhand eines Beispiels?


----------



## robotto7831a (11. Juni 2015)

Der Code funktioniert prima.


----------



## FirstS0ul (11. Juni 2015)

Okay ich habe Probleme mit einigen Subdomains...
Ein Beispiel:

Die Subdomain "webmail.first-s0ul.de" wurde im ISPC angelegt, dort als proxy redirect eingerichtet und folgendes in die Direktiven geschrieben:


```
access_log  /var/log/nginx/roundcube.access.log;
error_log  /var/log/nginx/roundcube.error.log;

if ($scheme != "https") {
rewrite ^ https://webmail.first-s0ul.de$request_uri? permanent;
}

location / {
  root /usr/share/roundcube;
  index index.php index.html index.htm;
  location ~ (.+\.php)$ {
  try_files $uri =404;
  include /etc/nginx/fastcgi_params;
  fastcgi_pass unix:/var/run/php5-fpm.sock;
  fastcgi_param HTTPS on;
  fastcgi_index index.php;
  fastcgi_intercept_errors on;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  fastcgi_buffer_size 128k;
  fastcgi_buffers 256 4k;
  fastcgi_busy_buffers_size 256k;
  fastcgi_temp_file_write_size 256k;
  }
}
```
Hier noch Screenshots:


----------



## JeGr (12. Juni 2015)

Warum denn als Proxy Redirect?! Und worauf? Macht gerade so irgendwie keinen Sinn für mich, zumal nirgends in deiner Subdomain Konfiguration jetzt irgendwas spannendes definiert ist. So siehts aus als würdest du - per proxy - die Domain auf die Hauptdomain ändern. Nur warum?


----------



## FirstS0ul (12. Juni 2015)

Wie soll ich den sonst eine Subdomain mit redirects erstellen? Ich kann bei sonst keiner Option bei einer Subdomain Direktiven einstellen... Ich bitte um eine erklärung.


----------



## JeGr (12. Juni 2015)

Du hast mich nicht ganz verstanden. Ich habe mich gefragt, warum du überhaupt die Subdomain via Proxy auf die Hauptdomain leitest. Da mags ja gute Gründe für geben, ich verstehe es aus dem Ansatz gerade nur nicht?
Ich habe das Web für den Webmailer eben als ganz normale Domain angelegt, eben mit seinem gewünschten Namen (webmail.domain.tld) und dann entsprechend alles andere vollständig durchkonfiguriert. Nur weil die Domain eine Subdomain beinhaltet (webmail....) musst du die Domain doch nicht als Subdomain in ISPConfig anlegen? Gerade wenn nur auf der Subdomain SSL laufen muss/soll oder was komplett anderes als im Webspace der normalen Domain würde ich das als extra Web anlegen um keinen Streß zu bekommen.


----------



## FirstS0ul (12. Juni 2015)

Mh okay. Mehr wollte ich nicht wissen... Dann muss ich ja für jede Subdomain eine Webseite anlegen oder eine VHost Subdomain... Ist auch keine schöne Lösung..

Naja die Gründe für den Proxy sind ganz einfach. Ich habe keine andere möglichkeit gefunden Direktiven für Subdomains anzulegen. Aber wenn ich die einfach als Webseite oder als VHost Subdomain anlege, dann ist das was anderes.


----------



## JeGr (12. Juni 2015)

Zitat von FirstS0ul:


> Dann muss ich ja für jede Subdomain eine Webseite anlegen oder eine VHost Subdomain... Ist auch keine schöne Lösung..


Nein musst du nicht, nur da wo es Sinn macht. Wenn es nur darum geht, dass verschiedene Pfade der Hauptdomain/Webspace via Subdomain erreichbar sein sollen (bspw. wenn dem Kunden nur ein Webspace mit Domain + 5 Subdomains o.ä. zugewiesen sind). Wie gesagt, es mag dann genug Situationen geben, wo das Sinn macht.
Wenn du aber für mehrere/alle Kunden einen Webmailer baust, dann ist das eher hinderlich und macht mehr Sinn, dass der auf einem eigenen dedizierten Webspace abgelegt wird. Dann kann man auch nicht über wilde Konstrukte einer anderen Website nicht zufällig in den Webmailer reingreifen.


----------



## Till (12. Juni 2015)

Zitat von FirstS0ul:


> Naja die Gründe für den Proxy sind ganz einfach. Ich habe keine andere möglichkeit gefunden Direktiven für Subdomains anzulegen. Aber wenn ich die einfach als Webseite oder als VHost Subdomain anlege, dann ist das was anderes.


Warum fügst Du sie nicht einfach in das Direktiven Feld der Haupt Webseite ein und umschließt sie mit einem if ($host ....... ?


----------



## FirstS0ul (12. Juni 2015)

Weil ich nicht wusste dass, das geht 
Könnte ich ein Codebeispiel haben?


----------



## JeGr (12. Juni 2015)

@Till weil das nicht geht  NGINX' Syntax beherrscht keine mehrfachen IFs und da der eigentliche Redirect schon ein if $scheme Konstrukt ist, kannst du da kein zweites If drumherum basteln.


----------



## Till (13. Juni 2015)

Es gibt ein paar workarounds, aber so richtig schön sind die in der tat nicht:

https://gist.github.com/jrom/1760790
http://rosslawley.co.uk/archive/old/2010/01/04/nginx-how-to-multiple-if-statements/


----------



## FirstS0ul (15. Juni 2015)

Also Löse ich das ganz als VHost Sudomain? Das wäre wohl die beste Lösung.


----------



## JeGr (15. Juni 2015)

Meines Erachtens nach die sinnvollste Variante, die Subdomain einfach als eigene Domain anzulegen mit allen mit einhergehenden Vorteilen.


----------



## FirstS0ul (15. Juni 2015)

Gute dann soll mir einer den Unterschied zwischen eigener Domain (Webseite) und VHost Subdomain erklären.


----------



## JeGr (15. Juni 2015)

Ich weiß nicht ob du dich jetzt gerade nur an Begrifflichkeiten aufhängst, aber ich verstehe die Frage nicht wirklich. Was dir geraten wurde, ist jetzt doch schon mehrfach klar diskutiert worden?
Neue Website anlegen, Domainname ist der komplette Name a.b.c.de und gut.
Vorher natürlich die Subdomain entfernen die jetzt angelegt ist.

Was ist daran nun schwer? Zudem kann man sein Anliegen auch ein klein wenig freundlicher anbringen.


----------



## Till (15. Juni 2015)

Zitat von FirstS0ul:


> Gute dann soll mir einer den Unterschied zwischen eigener Domain (Webseite) und VHost Subdomain erklären.


Das ist ganz einfach, eine vhost subdomain ist ein Hilfsmittel um im Notfall eine weitere Domain in ein Verzeichnis einer bestehenden Website einzublenden. Dies sollte man aber möglichst nicht machen da dies Sicherheitsnachteile hat denn die subdomain läuft dann unter dem selben User wie die haupt Seite, wenn Du also einen Shop hast und mittels vhost subdomain einen blog in die selbe Seite einblendest, dann kann man mit einem simplen hack des Blogs deinen Shop mit den Kreditkartendaten übernehmen.

Nimmst Du stattdessen einen eigene Website (so wie im Handbuch empfohlen), dann läuft jede Subdomain separat und unter einem eigenen user.


----------



## JeGr (15. Juni 2015)

@Till Um das noch hinzuzufügen - bevor die Frage wahrscheinlich kommt, warum es dann extra Subdomains gibt: Ich denke der ursprüngliche Subdomain Punkt, der auf ein Verzeichnis einer vorhandenen Domain zeigt, kommt auch mit aus der Zeit, in der Web Pakete gerne noch gebundelt waren mit "x Subdomains inklusive", welche bei den meisten Anbietern aber lediglich interne Rewrites auf Unterverzeichnisse des gleichen Webspace waren um den Verwaltungsaufwand so niedrig wie möglich zu halten.
Heute ist das aber aus genau von dir genannten Gründen schon aus Sicherheitssicht nicht unbedingt mehr wünschenswert, es sei denn, man arbeitet hier bspw. mit dem gleichen System im Hintergrund (bspw. ein CMS, welches Sprachen via Subdomains in Ordner abbildet - gibt es einige). Für diese ist die Einstellung über den Subdomain Menüpunkt dann sehr simpel und wenig fehleranfällig.
Deshalb gibt es aber auch den Konfigurationspunkt "Subdomain als eigene Domain anlegen". Wird der dann eigentlich noch gebraucht, wenn man es ja eh als normale Domain anlegen kann? Oder zählt das intern dann gegen das Subdomain Limit und der normale Webspace nicht (war meine Vermutung war)?

Grüße
-jens


----------



## Till (15. Juni 2015)

Zitat von JeGr:


> Deshalb gibt es aber auch den Konfigurationspunkt "Subdomain als eigene Domain anlegen". Wird der dann eigentlich noch gebraucht, wenn man es ja eh als normale Domain anlegen kann? Oder zählt das intern dann gegen das Subdomain Limit und der normale Webspace nicht (war meine Vermutung war)?


Erstmal vorweg, wenn es nach mir ginge würde es den Menüpunkt "Subdomain als eigene Domain anlegen" nicht geben und ich habe ihn bislang auch aus den von mir genannten Gründen nicht verwendet. Daher ist er auch per default ausgeblendet, um die Nutzer nicht zu verwirren und da er aus Sicherheitsgründen nicht verwendet werden sollte. Es gibt diese Option nur auf Wunsch vieler User, wahrscheinlich weil es das in anderen Panels auch gibt und weil User oft ein Problem damit haben dass man für jede Website einen eigenen FTP User braucht. Die vhost subdomain zählt natürlich auch zum HD quota der Website, das mag einer der Gründe sein dass Hoster es verwenden damit sie ihren usern "unlimited" subdomains verkaufen können ohne dass sich der User entscheiden muss, wie er seinen Webspace aufteilt.

Die normale "Subdomain" oder "Aliasdomain" Funktion braucht man wie von Dir angemerkt nur für multidomain CMS Systeme oder aber wenn man eine Domain als .de, com, net, etc. hat und diese dann per 301 "SEO" redirect auf die Hauptdomain umbiegt.


----------



## FirstS0ul (16. Juni 2015)

SUPER! Vielen Dank. Dann werde ich alle Subdomains in "Domains" umwandeln. Dann sollte sich einiges von selbst Lösen. Muss nur mein Kopf sortieren.

Danke Jungs. Ich melde mich.


----------



## FirstS0ul (16. Juni 2015)

Nennt mich doof oder so. Aber langsam bin ich mit meinem Latein am Ende!
Was mache ich Falsch?!


----------



## JeGr (16. Juni 2015)

Doof. 
Im Ernst: Wenn du keinerlei Problem schilderst - was soll man dir dann als Hilfestellung sagen? Du postest 3 Bilder. Und jetzt? Sorry aber meine Glaskugel hat grad nen Lampendefekt  WAS genau geht jetzt damit nicht?


----------



## FirstS0ul (16. Juni 2015)

Nichts...
geh doch auch webmail.first-s0ul.de
Bekomme ja nicht mal Roundcube?
Ist die Config überhaupt korrekt?


----------



## JeGr (16. Juni 2015)

Öhm nein, warum sollte da auch was kommen? Du schreibst zwar irgendwelchen Kram von /usr/share/roundcube in deine Konfiguration rein, davon wirds aber auch nicht wahr. Dein Document Root für *jeden Webspace* ist immer /var/www/<client>/<web>/web/ also sollte auch in diesem Verzeichnis ein Roundcube installiert sein. Du kannst doch jetzt nicht irgendein Webspace neu anlegen und auf irgendeinen wilden Pfad auf dem Server zeigen lassen. Ich weiß ja nicht aus welcher Doku oder Howto das hast, aber keine von hier. Die einzige Doku zu Roundcube mit diesem Pfad beschreibt aber auch den Einsatz von Roundcube als App bzw. als händisch angelegter VHost und nicht als Webspace der in ISPC3 angelegt wird. Zudem ist meist bei Debian/Ubuntu die roundcube Version derbe veraltet, so dass es eh keinen großen Sinn macht die zu nutzen.
Einfach mal hergehen und das Ding von roundcube.net runterladen, da reinwerfen und entpacken und installieren.

Siehe bspw. https://www.howtoforge.com/using-roundcube-webmail-with-ispconfig-3-on-debian-wheezy-nginx
Dort wird aber als location /roundcube angegeben, nicht /usr/share/roundcube. Zudem ist vorher "root /var/lib" als root-dir / document root gesetzt.

Ich würde trotzdem raten eine saubere Neuinstallation von Roundcube (latest stable) zu machen, anstatt eine alte Version aus den Repos zu nutzen. Man muss sie dann eben selbst pflegen.


----------



## FirstS0ul (16. Juni 2015)

Das ist doch völlig bescheuert?! Dann brauche ich auch keinen "Webseite/Domain/Was auch immer" anlegen. ISPC legt dann User und Ordner etc an. Roundcube liegt in /usr/share/roundcube in deinem Link liegt es unter /var/lib/roundcube, also spielt es erstmal keine Rolle. die Roundcube Version spielt auch keine Rolle (Ich habe die letzte, mal abgesehen davon).
In meiner roundcube Instanz steckt zu viel arbeit um es jetzt umzuziehen oder der gleichen... Das wird ganz bestimmt nicht neuinstalliert.

In dem Tuto ist es doch gut beschrieben... Das ganze möchte ich nur auf eine Subdomain und nicht auf www.wasweisich.de/webmail
Ich glaube wir sprechen hier alle einander vorbei.
Vorher, ohne SSL, hat es Prima funktioniert. Jetzt möchte ich nur das mit SSL...

Genauso wie ich Subdomains habe die auf ein Verzeinis des Doc. Roots der Domain zugreifen, kann ich ja auch nicht weiterleiten. Warum ist das dann so kompliziert? Warum kann ich einer Subdomain kein SSL verpassen über den normalen Weg wie es jeder machen würde? Ich muss eine Webseite anlegen? Blödsinn. Das kann doch nicht der Sinn davon sein. Und das tolle Handbuch, was ich mir auch noch gekauft habe... hilft bei der Sache gar nicht...


----------



## FirstS0ul (16. Juni 2015)

Okay. War ein rauchen. Gedanken sortiert. Jetzt klappt es. Ich mache mal weiter. 
Habe es über Webseite erstellen gelöst und mit dem Tuto oben kombiniert.


----------

