Synology-Forum.nl
Overige software => Web Station => Topic gestart door: reindu op 01 augustus 2019, 21:52:23
-
Ik heb drie websites op mijn synology draaien via virtual host. Nou wil ik ze graag met HTTPS.
Ik ben eerst begonnen als test met de DDNS site van synology mijndomein.synology.me. Ik heb de gebruiksaanwijzing gevolgd voor het halen van een letsencrypt en alles geinstalleerd. Dat lukt wel, maar ondanks dat je via control panel/ network/DSM settings: Automatically redirect HTTP to HTTPS aanklikt, bereik je je DSM interface alleen via https met mijndomein.synology.me:5001. Het URL hoort toch automatisch naar https te gaan?
Maar nu de sites via virtual host, dat lukt voor geen meter. Wat ik ook doe, de site is niet bereikbaar. Niet helemaal duidelijk is voor mij hoe het met de poorten gaat. Het synology adres loopt via 5001, de andere via 443.
Googelen leverde dat je om vanuit de server HTTPS te forceren een .htaccess bestand moet aanmaken in de web share. Dus kan het niet via alleen de DSM interface?
-
Wat heb je als poorten ingevuld staan bij Netwerk/DSM instellingen?
Als je daar bij HTTPS poort 443 hebt staan, gaat het niet goed... die is voor de websites bedoeld. Daar dus een afwijkende poost opgeven, bijv 5020, en dan in je router die poort forwarden naar de NAS.
En ja, om bij de DSM desktop te komen, moet ook ik https: //www .mijndomein.nl:5020 opgeven (zonder de spaties, uiteraard, da's alleen om er hier geen link van te maken)... maar dan kom ik er wel!
-
Het is een zeer incompleet verhaal waar veel mist. Als het altijd al met virtual hosts werkte, moet het nog steeds weken zoals jij het beschrijft.
Lees de Help eens grondig door want daar wordt het goed uitgelegd. Beter dan de halve reacties die je hier zilt krijgen. Zeker omdat je alles door elkaar vraagt met virtual host, dsm toegang en ddns. (Waar ddns nu plotseling voor nodig is weet ik niet, want die websites draaiden toch altijd al goed?)
Het lijkt me dat je hier drie of vier problemen in een keer wilt aanpakken. Tip: Doe het per probleem.
-
OK, blijkbaar is mijndsm.synology.me:5001 dus de goede manier om via https je dsm te bereiken. Ik heb daarvoor een letsencrypt certificaat dat ik default instel. Dan geldt hij blijkbaar voor alle andere websites, maar die zijn nog steeds niet met https bereikbaar.
Toen een certificaat ge-add voor mijn met web-station geinstalleerde site www.eigensite.nl, en die via configure eraan gehaakt. De site is dan nog bereikbaar met http, maar nog steeds niet met https. Had ik in het schermpje virtual host wat moeten doen? Daar staat alleen een vinkje bij 80/443
-
Zet eens een vinkje bij HSTS en kijk of dat het gewenste resultaat oplevert.
Hier uitleg wat het is :
https://vevida.com/help/http-strict-transport-security-hsts-inschakelen/
-
Geen effect
-
Een redirect van http naar https is iets wat de websitebouwer zelf moet doen. Hier blijft DSM keurig van af, want elke website doet dat anders. Dat staat ook duidelijk naast de eerder genoemde checkbox. (Maar mensen lezen nooit)
Het gebruik van HSTS is pas aan te raden als de website werkt. Als je het eerder aanzet, frustreert het alleen je eigen testen voor een werkende redirect.
-
Je kunt met .htaccess in de Web shared folder het verkeer op poort 80 redirecten naar 443 en requests voor domeinen ombuigen (bijv domein.com naar www.domein.com).
Het verkeer van buiten kan allemaal op dezelfde twee poorten HTTP/80- HTTPS/443 binnenkomen en de rewrite rules zorgen ervoor dat het juiste verkeer naar de juiste site wordt geforward.
(Instructies voor DSM 6.2.2.24922 update 2)
Instellingen in web station:
- Virtual Host: "Name-based"
- vul de (sub)domeinnaam in waar de site op moet reageren, bijv "domein.com".
- port: vink bij 80/443
- laat hsts en http/2 nog even uit.
Instellingen Control Panel / Security / tab Certificate:
- Voeg een certificaat toe voor je domein; Let's encrypt is prima. Maak een certificaat aan met meerdere "Subject Alternative names". het certificaat wordt dan geschikt voor meerdere subdomeinen. Bijvoorbeeld "domein.com" met alternative names "www.domein.com", "nogiets.domein.com".
- Kies "configure" knop om het juiste certificaat te koppelen aan de juiste "service"=virtual host
Instellingen shared folder web\.htaccess:
# redirect "http://domein.com", "http://allesbehalvewww.domein.com", maar ook "https://domein.com" naar https://www.domein.com
RewriteCond %{HTTP_HOST} ^!(www\.)domein\.com$ [OR,NC]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.domein.com%{REQUEST_URI} [R=301,L]
(ik hoop dat ik de bovenstaande condities juist heb opgesteld, want ik doe dit uit mn hoofd).
Op het moment dat de Synology de request hostname niet kan matchen op virtual hostnames / reverse proxy namen, dan gaat ie de .htaccess nalopen en kan je via rewrite rules http->https redirects en subdomein redirects laten uitvoeren.
Toegang tot je DSM via domeinnaam "dsm.domein.com" kun je via "customized domain" instellen:
Instellingen Control Panel / Network / DSM Settings
- Aanvinken "Automatically redirect HTTP connections to HTTPS (Web Statin and Photo Station excluded)"!
- Domain Enable customized domain: aanvinken
- Domain: dsm.domein.com
- (Enable HSTS mag aan staan)
"dsm.domein.com" (http of https) zal nu je DSM pagina van je NAS openen.
Laatste tip: met reverse proxy kun je ook nog leuke dingen doen. Mijn Synology draait een paar Docker images met web sites die luisteren naar requests op rare poorten, bijvoorbeeld 43443. Via een reverse proxy entry wordt het verkeer voor een hostname geredirect naar http://localhost:43443 waar de web server in het Docker image op HTTP (NIET https) luistert. De Synology zorgt via de reverse proxy en certificaat voor "offloading" van het HTTPS verkeer, terwijl de web server in de Docker Image http mag blijven doen; geen moeilijke dingen in de Docker image met https of certificaten.
Instellingen Control Panel / Application Portal / Reverse proxy
- Description: wat je wil
- Source protocol: HTTPS
- Source hostname: webapp.domein.com
- Source port: 443
- Destination protocol: HTTP
- Destination hostname: localhost
- port: 43443
(De web applicatie die ik draai in Docker is een ASP.NET Core web applicatie; gewoon geweldig dat ik een webapp kan ontwikkelen op mn Windows laptop, debuggen, inpakken in een Docker image en kan draaien op een Synology Linux omgeving!)
-
Je kan geen Docker draaien op de DS213+ ;)
-
't is maar een tip dat je met de reverse proxy domeinnamen kunt koppelen aan services op de Synology. Naast Docker (ik heb een DS415+), kun je bijvoorbeeld "https://files.domein.com koppelen aan FileStation (http://localhost:7001)
-
Ik heb zelf de site in PHP gemaakt, dus er stond geen .htaccess file in. Ik heb er eentje gemaakt volgens het sjabloon van VictorV, maar geen effect. De website is buiten niet te bereiken.
-
Een oorzaak gevonden: ik had in de zonefiles een CNAME staan, die verwees naar mijndomein.synology.me. Blij, ik dacht dat het probleem opgelost was en die weg gehaald. Maar de ellende gaat door. Ook met de aanwijzingen VictorV geen https. Bovendien zit ik nu met het ergste probleem, dat het me niet lukt om de zaak terug te draaien. Internet heeft een soort geheugen, als ik http intik wil hij https, ondanks dat ik de browsercache leeg. Kortom, mijn site is nu al een week uit de lucht, en ik kan er niets aan doen.
-
De verbinding met IP klopte ook niet, nu een DHCP-binding ip in de router vastgezet, en in de NAS control panel/Network interface/LAN/edit DHCP auto gezet. Eea stond al jaren verkeerd, maar de websites draaiden, dus nooit naar gekeken.
De andere websites draaien nog steeds, maar https of http op mijndomein.nl ho maar. Bij mijn vele pogingen eens mijndomein.nl:443 ingetikt, dan kreeg ik een van de IP-camera's, maar dat mag voor https toch niet uitmaken?
-
Dat was de voornaamste oorzaak van het probleem. Na het veranderen van de poort van de IP camera, was https meteen bereikbaar. Toch heb ik nog een vraag; de browser (oa Chrome) geeft geen 'slotje' en zegt dat de verbinding niet helemaal veilig is. Is Lets Encrypt niet goed genoeg?
-
Ook hiervan heb ik nu zelf de reden gevonden. Een van de browsers verduidelijkte de oorzaak in zijn info-knopje: op de pagina's kon een link naar een niet beveiligde pagina staan. In mijn geval hadden alle plaatjes op mijn website een link naar hun directory met http ipv https. Overal weer een slotje!
-
Het probleem is nu opgelost in de site, waarvan ik de php-pagina's zelf controleer. Nu komt de volgende vraag: hoe zit dat met een Wordpress-site, die wil ik nu naar https omzetten. Is daar in de shell een optie voor, want anders verwijst hij intern toch ook met http links?
-
Als je websites beheert, moet je je ook vertrouwd maken met de diverse ontwikkeltools van browsers. Vooral het error log is waardevol bij problemen. Je kunt zelfs "live" de code van websites aanpassen en een refresh doen om dingen snel te testen.
-
De Wordpresss-sites hebben nu ook een slotje. Ik heb de stappen van VictorV ook hierbij gevolgd, en de inhoud van .htaccess volgens zijn script aangepast. Vervolgens met phpMyAdmin in de Wordpressdatabase in de velden `siteurl` en `home` de http in https veranderd. In het VictorV antwoord stond `laat hsts en http/2 nog even uit`. Waarom was dat, en kunnen ze nu aan? Want in wat ik daarover lees, is het een betere redirect.
-
hsts is code in de header van een TCP pakket die de browser vertelt dat de site ook https kent en dat de site wil dat dat in toekomst gebruikt wordt. Er staat ook bij hoe lang dat geldig is. (Meestal een half tot één jaar).
Als je binnen die tijd probeert in te loggen met http, dan zal de browser dit uit zichzelf veranderen in een https inlog. Dus ook als je de optie op de nas weer uit zet, zal de browser niet meer via gewoon http willen inloggen. Tijdens het testen is dat frustrerend omdat je bij een certificaat probleem niet even via http binnen kunt komen, ook al heb je de redirect naar https op de nas weer uit gezet.
Zonder hsts kun je nog steeds een mit aanval uitvoeren als de gebruiker eerst een verbinding via http opzet.
-
Bedankt! Ik zal ze nu aanvinken.
-
Bij een van de wordpress-sites gaven de links een 404 error. De https link verscheen wel goed in de URL balk, maar als je met je muis over de link ging, was er http.
Zoeken op wordpresssites gaf aan, dat bij het overgaan naar https, je in config_wp.php je
define('FORCE_SSL_ADMIN', true); moest toevoegen. Dat maakte niets uit.
Op de wordpress facebookgroep kwam toen de suggestie, om de permalink instellingen opnieuw op te slaan, en dat was de oplossing.
Ik heb de admin force maar weggehaald.