AWS EC2 kann nicht verbinden mit https

[derocco]

Ports in der Sec group gesetzt.
Kann die Seite mit http erreichen. nicht aber mit https

Woran kann das liegen?

 

[xxhagixx]

Beim 443 Port fehlt die ::0 Quelle, die beim 80er Port vorhanden ist.
Siehe: https://aws.amazon.com/de/premiumsupport/knowledge-center/connect-http-https-ec2/

Die https Einstellungen über nginx oder Apache sind gesetzt?

 

[snaxilian]

• Du gehst über IPv6 auf die Kiste (nur tcp/80 ist für v4 und v6 erlaubt, tcp/443 nur auf v4...)
• Der Webserver läuft nur auf :80 aber nicht auf :443
• Webserver lauscht auf :443 aber macht einen Redirect auf http und :80

 

[Cokocool]

Weißt du überhaupt was du tust ? Als Amateur einen im Internet verfügbaren Server laufen zu lassen ist so eine Sache...

• Warum ist der MySQL Port offen ? Wenn du die DB auf dem Server hast, dann kann das Frontend doch per localhost drauf zugreifen oder kommst du von außen auf die DB ? Generell würde ich in AWS auf RDS setzen für die DB.
• Hast du überhaupt ein Zertifikat auf dem Server ?

 

[derocco]

sorry ::0 ist auch gemacht aber auf der nächsten Seite.

Mysql port ist offen damit ich mit einem ext client drauf kann.
Es ist nur ein testsystem. Das wird alles noch angepasst.

 

[KurzGedacht]

Um mit einem externen Client zuzugreifen nutzt man SSH Tunnel. Da sollte kein MySQL Port nach außen offen sein.

Läuft denn der Webserver überhaupt auf 443 (poste mal den Output von "sudo netstat -plant")?
Ich würde tendenziell empfehlen Https nicht am Webserver selber zu schalten sondern seitens AWS über einen ALB vor dem Webserver.
Dem Webserver am besten gar keine öffentliche IP geben.

 

[Hayda Ministral]

sorry ::0 ist auch gemacht aber auf der nächsten Seite.

Mysql port ist offen damit ich mit einem ext client drauf kann.
Es ist nur ein testsystem. Das wird alles noch angepasst.

Auch wenn's unbequem ist: Mittelfristig fährst Du besser wenn Du erst alles sperrst und dann gezielt und ausschließlich die Verbindungen zuläßt die Du wirklich brauchst.

Wenn Du aus welchem Grund auch immer im Moment von extern auf den mysql port zugreifen musst dann könntest Du diese Verbindung gezielt für Deine gegenwärtige IP erlauben. Die wird in der Regel zwar nicht statisch sein, aber vermutlich doch so lange Bestand haben dass der Aufwand überschaubar bleibt.

@All: Ja, ist gefrickel. Aber besser als nix und für einen der damit anfängt "machbar".

PS: Mach Dir bewußt, das öffentlich erreichbare IPs ständig gescannt werden. Und sobald sie gefunden wurden werden sie auf offene Ports untersucht. Und sowie die offenen Ports bekannt sind wird versucht darüber einzudringen. AWS ist hier zwar Dein Freund, kann aber nicht zuverlässig verhindern das pöhse Puben pädophilen islamistischen Raubmord-Kopier-Content in irgendeinem Unterverzeichnis des Webservers oder einer Tabelle der DB ablegen. Horrorszenario, mindestens so unwahrscheinlich wie vom Blitz getroffen zu werden. Aber würdest Du Dich bei einem Gewitter mit einem Eisenhelm auf dem Kopf auf einen Berg stellen, eine Eisenstange hoch halten und dabei rufen "Es gibt keine Götter"? Nein, würdest Du nicht. Also schließ die verdammten Ports, aber presto pronto ;-)

 

[snaxilian]

Es ist nur ein testsystem. Das wird alles noch angepasst.

Denkbar schlechteste Herangehensweise.
Wenn sich Test- und Produktivumgebung derart voneinander unterscheiden wirst du früher oder später Probleme oder Fehler in Prod sehen, die du in Test nicht hattest bzw. Dinge, die in Test liefen aber in Prod plötzlich nicht mehr.

Wenn du auf die DB remote zugreifen willst: VPN oder SSH Tunnel oder mindestens die Firewall auf deine IP einschränken aber doch nicht alles und jeden erlauben.

 

[derocco]

Es ist erst mal ein POC ob da alles so läuft wie wir das möchten.
Das ist alles noch nicht fix, aber bevor ich Zeit reinstecke....
Die Instanz läuft auch nur wenn ich die starte...

Einen Loadbalancer kann man da klar drauf machen. Aber das ist jetzt mal erst ein overkill

 

[Cokocool]

Einen Loadbalancer kann man da klar drauf machen. Aber das ist jetzt mal erst ein overkill

Naja der ALB spart dir Zeit. Du musst dich nicht um das Zertifikat auf der EC2 Instanz kümmern, weil der ALB die SSL Terminierung übernimmt und einfach als (Reverse)-Proxy dient. Ein ALB+ACM übernimmt automatisch das Erneuern des SSL-Zertifikats auf dem ALB und Zertifikate mit ACM kosten nix

 

[derocco]

Naja der ALB spart dir Zeit. Du musst dich nicht um das Zertifikat auf der EC2 Instanz kümmern, weil der ALB die SSL Terminierung übernimmt und einfach als (Reverse)-Proxy dient. Ein ALB+ACM übernimmt automatisch das Erneuern des SSL-Zertifikats auf dem ALB und Zertifikate mit ACM kosten nix

Ah nice, ich dachte der ALB kostet extra.

Aber dann brauche ich auch 2 Instanzen? Ein Loadbalancer mit einer Instanz würde ja am Thema Balancing vorbei gehen.

 

[snaxilian]

dachte der ALB kostet extra

Korrekt. Bei AWS intern lautet die wichtigste Frage zuerst immer: Wie kann ich das abrechnen und erst danach kommt: Was bringt es für Vorteile für den Kunden.

Du kannst auch einen ALB mit nur einer Instanz nutzen, dann ist es halt ein reiner Reverse Proxy mit TLS Terminierung. Das kann man entweder bei AWS zusammen klicken als ALB oder wenn man es will und technisch kann einen der unzähligen alternativen Loadbalancer/Reverse Proxy Varianten nehmen wie HAproxy, Traefik, Caddy, das jwilder-nginx-proxy Konstrukt oder irgendwelche kommerziellen Lösungen wie F5 Big-IP, Citrix NetScaler, irgendwas passendes von Kemp o.ä.
Wenn man sich nicht mit dem Betrieb/Wartung beschäftigen will oder kann, kauft man es halt als Service ein.

 

[Cokocool]

Ah nice, ich dachte der ALB kostet extra.

Der ALB kostet ein wenig Geld, aber dafür ist das Zertifikat+ACM kostenlos. Der ALB ist halt komplett serverless und wird von AWS gemanaged. Es spart also wertvolle Arbeitszeit

Aber dann brauche ich auch 2 Instanzen? Ein Loadbalancer mit einer Instanz würde ja am Thema Balancing vorbei gehen.

Eine Instanz reicht für nen PoC und versteif dich nicht auf den Namen Balancing. Auch ohne Nutzung von Loadbalancing hat der ALB genug Vorteile, die ich und @snaxilian bereits genannt haben.