nexus_VI
Overnumerousness!
|
Du kannst wahlweise ein Zertifikat für alle Domains erstellen, oder separate Zertifikate für jede Domain (server_name bei Nginx).
|
Viper780
ModeratorEr ist tot, Jim!
|
Afaik sind dann alle anderen Domains über die Hauptdomain zertifiziert, Subdomains außer für die Hauptdomain gehen dann glaube ich auch nicht. Oder täusche ich mich mit den zwei Aussagen? Früher war das ein Problem. Mit SNI https://de.wikipedia.org/wiki/Server_Name_Indication und dem server_name im TLS Header geht es auch anders. Best Practice ist aber nach wie vor eine eigene IP für Port 443 und eine für Port 80 In meinen Setups hab ich aber jedesmal drauf verzichtet.
|
COLOSSUS
AdministratorGNUltra
|
Best Practice ist aber nach wie vor eine eigene IP für Port 443 und eine für Port 80 Diese Aussage ergibt nur extrem wenig Sinn. Weiters gibt es heute keine benutzbaren TLS-Clients mehr, die keinen SNI-Support haben. Man kann (und in der Praxis: hat) beliebig viele TLS/X.509-Zertifikate auf einem listening socket (haben).
|
Viper780
ModeratorEr ist tot, Jim!
|
Diese Aussage ergibt nur extrem wenig Sinn. Technisch mag das stimmen, aber ca eine halbe Mio Webserver in Deutschland und Österreich sind bei den großen Hostern so konfiguriert
|
Smut
takeover & ether
|
Diese Aussage ergibt nur extrem wenig Sinn.
Weiters gibt es heute keine benutzbaren TLS-Clients mehr, die keinen SNI-Support haben. Man kann (und in der Praxis: hat) beliebig viele TLS/X.509-Zertifikate auf einem listening socket (haben). Wie machst heute let’s encrypt verification ohne port 80? Klappt das mittlerweile auf 443?
|
Viper780
ModeratorEr ist tot, Jim!
|
Wie machst heute let’s encrypt verification ohne port 80? Klappt das mittlerweile auf 443? DNS-01 (bevorzugt und nur damit geht Wildcard) oder ALPN-01 HTTP-01 geht aber auch mit https auf Port 443 - du brauchst aber schon mal ein gültiges Zertifikat
|
Rogaahl
Super Moderatorinterrupt
|
Du kannst wahlweise ein Zertifikat für alle Domains erstellen, oder separate Zertifikate für jede Domain (server_name bei Nginx). Danke, müsste ich mir mal genauer ansehen, ergibt natürlich Sinn, dass es geht. Es erscheint es mir ziemlich umständlich, vor allem mit dem swag/letsencrypt Containern gibt es keine schnell deployable Lösung, und finden tut man diesbezüglich nur wenig Information. _Aber_ ist in dem fall jetzt eh egal, weil ich viel lieber die gschichtln auf kleine vps aufteile und somit auch keine IP Assoziation stattfinden kann, nachdem alle cert Informationen öffentlich einsehbar sind.
|
TOM
Super ModeratorOldschool OC.at'ler
|
Um wieder zurück zu den VPS Anbietern zu kommen: Ich werfe nach meiner Recherche noch https://www.hostinger.de/ in die Anbieterliste. Hat bei den Tests die ich gefunden habe recht performant und günstig abgeschnitten. Nachteil den ich gefunden habe, "nur" 100 Mbit Anbindung und nur ein Snapshot pro Woche inkludiert. Hat mit dem jemand schon Erfahrungen gemacht? Netcup und Ipax schauen an sich recht nett aus. Habt Ihr best practice Anleitungen bzgl. VPS Absicherungen/Konfigurationen bei der Hand, die ihr nutzt um die Kisten im Netz abzusichern? (SSH Ports ändern, Keys, fail2ban, etc.) Sonst irgendwelche Tools die man sich für einen performanten modernen Webserver mit TLS Absicherung via LetsEncrypt anschauen sollte? Swag kannte ich z.B. bisher nicht, hab nur von Traefik und dergleichen als Reverse Proxy / SSL Offloading gelesen bisher. Würd mich gern mehr mit Static Site Generatoren spielen inkl. hug of death prevention via Cloudflare als free CDN (z.B.)... einfach aus Spielelaune
|
Rogaahl
Super Moderatorinterrupt
|
Am Server selbst nur ein geändertes ssh port offen. Theoretisch könnte man "kein port offen haben", wenn man sich über einen transparenten wireguard server verbindet. vps haben meistens keine FW dabei, dafür verwende ich ufw, allerdings Vorsicht, docker überspringt mit den defaults Settings die fw! Mit route allow geht es gut, wie hier beschrieben: https://github.com/chaifeng/ufw-dockerSSH hardening: https://medium.com/@jasonrigden/har...sh-1bcb99cd4cefaktuelle auditing scripts: https://github.com/jtesta/ssh-audit+ fail2ban für ssh Alle anderen Dienste sind dann nur per reverse proxy mit port 80/443 über den swag Container offen, der Container hat auch fail2ban für http auth. Bin aber auch kein pro, vielleicht haben andere hier bessere Tipps. Würd mich gern mehr mit Static Site Generatoren spielen Das muss ich mir auch mal ansehen!
|
COLOSSUS
AdministratorGNUltra
|
OpenSSH sshd so konfigurieren, dass man nur noch per Public Key Auth reinkommen kann - fertig. Mehr mache ich seit vielen Jahren nicht, um einen Server "abzusichern".
Manche Dienste mit auth vertragen vor sich sowas wie fail2ban als Bruteforce-Erschwernis ganz gut - ist aber in der Regel unnotwendig und kann durchaus auch Probleme verursachen.
|
jousch
Bloody Newbie
|
Ich hab gute Erfahrung mit hetzner cloud. Linode und Netcup klappt auch gut. Ich werde mir in Kürze mal easyname ansehen. Das shared Hosting dort ist nicht soo gut, aber bin gespannt was die VPSn dort hergeebn.
|
JDK
Oberwortwart
|
|
Anmeldung