Synology-Forum.nl
Synology Router => Synology Router => Topic gestart door: ddewit op 06 december 2015, 16:44:20
-
Weet iemand hoe ik een (beveiligde) verbinding kan maken via een subdomein naar de SRM / Synology router?
Ik heb dat eerder gemaakt voor mijn NAS via de beschrijving van Luke Vredeveld http://www.lukevredeveld.nl/wordpress/?p=234 maar in de RSM zie ik geen mogelijkheid om de virtuele server aan te maken en daar de doorwijzing naar de poort (8000 of 8001) goed te zetten.
Btw startssl certificaat is geinstalleerd voor router.[domeinnaam].nl
-
Iemand een idee?
-
Even los van die certificaten. (Ik gebruik als basis een zelfondertekend Synology certificaat).
Met wat ik begrijp uit die beschrijving van Luke Vredeveld wordt die doorverwijzing gemaakt in de gebruiksinterface van een reguliere hosting-provider met een domeinregistratie, dus niet in je router. Op die wijze heb ik de test in ieder geval gedaan.
De gebruikersinterface (CPanel) van mijn reguliere website biedt direct een commando om een redirect te maken.
Er wordt niet alleen een index.html bestandje aangemaakt, maar teven een .htaccess bestandje waarin een aantal varianten in schrijfwijzen van adressering worden meegenomen die dan ook blijven werken. Varianten bijv. met of zonder toevoeging www vooraf aan het domein e.d.
Het index.html bestandje verwijst naar mijn thuis WAN IP-adres op basis van een synology DDNS-domein,
aangevuld met :8001/webman/index.cgi
Waarbij regulier-domein.nl staat voor mijn webserver bij een hostingprovider.
test.regulier-domein.nl het subdomein
De volgende code voor de index.html, waarbij je voor [ hier je DDNS domein ] je Synology DDNS domeinnaam invult.
<html>
<meta http-equiv="refresh" content="0;url=https://[ hier je DDNS domein ].synology.me:8001/webman/index.cgi" />
</html>
Met de redirect kwam ik netjes thuis uit in de SRM gebruiksinterface van de RT1900ac router als versleutelde https verbinding.
Een vergelijkbare test heb ik gedaan met verwijzing naar de NAS met een ander sub-domein, en ook dat werkt.
Het voorbeeld van Luke Vredeveld mist in de coderegel helemaal aan het eind die laatste slash /
Misschien zit daar het verschil?
-
waarom niet via dns
router.mijndomein.nl - ipadres waarnaar toe
of als het via een bepaalde poort verwijzing moet dan een srv record aanmaken in je dns en je subdomein wel in je a record gooien
-
Hoe bedoel je dat? In de DNS-server?
Zelf heb ik die niet (meer) geïnstalleerd op de router, @ddewit wel.
In mijn geval komt het prima uit met de websites die ik reeds bij een reguliere hostingprovider heb lopen.
Met die domeinnamen, kan ik met subdomeinen nu mooi de functionaliteit naar router en nas doortrekken.
-
in dit geval van je hosting provider
kan je dus doen in cpanel of directadmin
-
bij de hostingprovider die ik heb (fxw) kan ik,naar mijn weten,geen poort meegeven in de dns. ze werken met direct admin maar de dns is een apart systeem.
ik zal kijken naar een srv bestand is.
kan zoiets (een poort meegeven naast de ip) wel met de dns van de Synology router?
-
tuurlijk wel je kan toch txt in je dns aan maken en daar het srv record plaatsen
wordt dan zoiets protocolname._tcp.domeinnaam.nl SRV 0 5 5000 domeinnaam.nl
-
bij de hostingprovider die ik heb (fxw) kan ik,naar mijn weten,geen poort meegeven in de dns. ze werken met direct admin maar de dns is een apart systeem.
Bij mijn hostingprovider heb ik voor de ene website met CPanel niets in een DNS record veranderd. (Ik zou ook niet weten hoe dat moet).
Er is bij CPanel een menu om een sub-domein toe te voegen.
Wordt er automatisch een mapje in de directory aangemaakt waarin een index-bestandje komt te staan met de bijbehorende code.
Echter in de regel van dat sub-domein waarnaar het moet verwijzen, vul ik dan de URL in naar mijn WAN-connectie, router of NAS.
Dat werkt dan daarna als zodanig.
In mijn geval het meest linker incoontje om de betreffende functie op te roepen.
[attachimg=1]
Ik vermoed dat andere web-server gebruikersinterfaces vergelijkbare functies hebben.
Mijn andere website die ik ook heb draaien, maar dan onder DirectAdmin heeft inderdaad een vergelijkbare functie. Ook daar werkt het mee.
[attachimg=2]
-
dit heb ik in mijn cpanel
(https://www.synology-forum.nl/proxy.php?request=http%3A%2F%2Fmr-d.nl%2Ftweak%2Fdns.PNG&hash=0a78082b76f8c0d847d81132d10cabe4683c8df1)
klik ik op geavanceerde dns dan zie ik bv dit
(https://www.synology-forum.nl/proxy.php?request=http%3A%2F%2Fmr-d.nl%2Ftweak%2Ftest.PNG&hash=d26fc08b7f4de2d715b3c791a97d806d7a8cf2ea)
-
Kennelijk twee benaderingswijzen hoe op te lossen.
Daar moet dan wel uit te komen zijn.
-
mompelt iets over Rome :lol: ;D
-
...en dat nog wel in een jubeljaar :lol:
-
Alternatief is gebruik maken van een iframe met je ddns adres.
-
Met alle veiligheidsrisico's voor lief nemend
-
Bij FXW wordt vanuit de DNS doorsturen naar een ip mét poort niet ondersteund hebben ze me laten weten. Ikweet weinig op het gebied van dns's dus geen idee hoe het dan zou moeten.
Ik heb t volgende getracht met het aanmake van een subdomein in Direct Admin
Wordt er automatisch een mapje in de directory aangemaakt waarin een index-bestandje komt te staan met de bijbehorende code.
Echter in de regel van dat sub-domein waarnaar het moet verwijzen, vul ik dan de URL in naar mijn WAN-connectie, router of NAS.
In DNS sundomein router.domein.nl naar wan ip nas verwezen
Bij mij maakt DirectAdmin bij het aanmaken van een sundomein een leeg index.html bestand aan waarinik heb gezet:
<html>
<head>
<meta HTTP-EQUIV=”REFRESH” content=”0; url=https://router.domeinnaam.nl:8001/webman/index.cgi″>
</head>
</html>
maar dat werkt niet,ikkrijg error in Chrome
Je verbinding is niet privé
Aanvallers proberen mogelijk je gegevens van router.domein.nl te stelen (bijvoorbeeld wachtwoorden, berichten of creditcarddetails). NET::ERR_CERT_COMMON_NAME_INVALID
-
Ik doe het via virtal hosts, waar het volgende index bestand in staat:
<!DOCTYPE HTML>
<html lang="en-US">
<head>
<meta charset="UTF-8">
<meta http-equiv="refresh" content="1;url=https://mijndomein.nl:8156">
<script type="text/javascript">
window.location.href = "https://mijndomein.nl:8156"
</script>
<title>Page Redirection</title>
</head>
<body>
<!-- Note: don't tell people to `click` the link, just tell them that it is a link. -->
If you are not redirected automatically, <a href='https://mijndomein.nl:8156'>goto Camera 6 login page</a>
</body>
</html>
Vergelijkbaar met jouw voorbeeld. Maar hij probeert de re-direct eerst ia javascript Pas als dat niet lukt (omdat het uit staat) gebruikt hij jouw code. En als dat niet lukt komt de body tekst in de browser staan als 2e backup methode.
Ook chrome geeft hier geen klachten over.
-
@ddewit
Ik heb het nog even opnieuw geprobeerd met Direct Admin, en een subdomein "test-twee".
In tegenstelling tot CPanel waarin je in een vervolgstap dan nog een link toevoegt naar een URL die in dat index.html bestand wordt opgenomen, gebeurt dat bij Direct Admin niet. Er wordt een "tekst opmaak" index.html bestand aangemaakt, waarin binnen een kader enkel de tekst:
"This is a placeholder for the subdomain test-twee[ mijn domein]"
Maar verander ik die handmatig, werkt het weer volledig correct.
Maar zoals ik al eerder aanhaalde in een vorig bericht (http://www.synology-forum.nl/synology-router/met-router-rsm-beveiligd-verbinden-%28-via-subdomein-%29/msg176218/#msg176218) zit het hem mogelijk in die laatste slash "/" aan het eind van de regel (waarachter dan nog een afsluithaakje">"), die jij nu ook weer consequent niet in je coderegel opneemt en ik wel. Verder gebruik ik de tags "head" helemaal niet.
<html>
<head>
<meta HTTP-EQUIV=”REFRESH” content=”0; url=https://router.domeinnaam.nl:8001/webman/index.cgi″>
</head>
</html>
versus
<html>
<meta http-equiv="refresh" content="0;url=https://router.domeinnaam:8001/webman/index.cgi" /> aan het eind die extra slash :!:
</html>
-
@Babylonia zou je een scrshot kunnen sturen van hoe dat bij jou in Direct Admin eruit ziet tijdens het aanmaken? Ik heb zelf een subdomein router.domein.nl aangemaakt. Direct admin maakt dan geloof ik in de map publiek_html een map router aan. Ik neem aan dat daar dat index.html bestand in moet?
[attach=2]
[attach=1]
En dan staat er dit in dat index.html bestand:
[attach=3]
Edit:
Ik zie nu dat er 2 mappen router bestaand.Blijkbaar maakt Direct Admin in mijn geval 2 mappen aan. Waarom en welke ik dan nu moet gebruiken is met niet duidelijk.Ook staat wel in beide een index.html bestand. Ik zal beide gelijk maken met een redirect.
[attach=4]
Mbt die forward slash /. Op mijn Nas heb ik t ook opgelost met een virtualhost en daarin dan een redirect met de locatie mét poort, maar zonder de / op het einde en dat werkt. Ik weet niet hoe je het officieel moet schrijven/syntax maar ik zal t beide testen.
@Briolet Ik kan op de router (Srm) geen virtual hosts aanmaken naar mijn weten dus ik hoop dat het doorsturen naar ip mét poort lukt via het aanmaken van subdomeins direct admin.
Ook overweeg ik omdat Fxw het doorsturen naar ip mét poort niet ondersteund vanuit het Dns om volledig zelf Dns te gaan draaien als dit vanuit de Synology Dns wel kan. Wel heeft @Ds211 me in eerder bericht geattandeerd op een srv bestand opnemen. Dat moet ik nog uitzoeken. Wellicht kan iemand me vertellen of er voor en nadelen zitten aan het zelf draaien van een publiek dns?
-
nadeel is dat je maar een ip voor je nameserver hebt en dat is zeker niet goed minimaal is 2, 3 is beter
-
ik heb de synology router en een nas thuis. Ook heb ik een nas op mijn studio staan. Das op een ander ip. Daar zou ik ook dns kunnen draaien dan heb ik er al 2.
Moet ik op beide dns servers dan ook al mijn dns instellingen dupliceren / 2 maal instellen?
Edit:en is ergens bijvoorbeeld een boekwerk dat de DNS server uitlegd? Ik kan nu elke keer alles Googlen maar mis het overzicht.
-
bedoel je zoiets ??
https://www.sylconia.nl/weblog-artikel/13/Uitleg+over+een+DNS+zone+record+DNS+voor+dummies/ (https://www.sylconia.nl/weblog-artikel/13/Uitleg+over+een+DNS+zone+record+DNS+voor+dummies/)
-
Als ik rechtstreeks inde browser adresbalk in geef: https://[ip]:8001/webman/index.cgi dan kom ik bij de SRM uit.
[attach=1]
Ik heb nu in beide router mappen de volgende gelijke tekst inde index.html bestand gezet:
<html>
<meta http-equiv="refresh" content="0;url=https://[ip]:8001/webman/index.cgi" />
</html>
Alleen als ik de subdomeinnaam ingeef in de adresbalk router.domeinnaam.nl krijg ik olgende foutmelding in Chrome:
[attach=2]
-
dat is toch logisch
heb je een betaalde certificaat dan van een signing instantie zoals bv comodo
en daarvan werkt en standaard zowiezo niet ivm met poortnummers
zie certificaten staan standaard op 443
en wil je die melding niet krijgen is alleen een betaalde geschikt
-
Dat snapik. Ik heb nu een gratis certificaat van startssl aangemaakt en geimporteerd, maar "nornaal" wanneer ik dan toch met Ip nummer die pagina wil benaderenb krijg ik ook zo'n soort melding maar dan kan ik alsnog wel door naar de pagina. Nu kan ik ook helemaal niet verder..
Ik bedoel als ik de url met ip gewoon ingeef in de adresbalk gaat het goed, maar als ik het via de subdomeinnaam laat lopen krijg ik die melding
-
en via ie of ff ??
-
Ja via Edge werkt t. Ook de doorverwijzing vanuit de subdomein doet t.
Ik geef in router.domeinnaam.nl dan wordt ik doorgezet naar https://ip:8001/webman/index.cgi
Ik krijg dan natuurlijk wel de melding dat het certificaat niet klopt, maar kan dan wel verder klikken naar de webpagina (srm).
[attach=1]
[attach=2]
-
@Babylonia zou je een scrshot kunnen sturen van hoe dat bij jou in Direct Admin eruit ziet tijdens het aanmaken?
Met de schermafdrukken van jou situatie (mogelijk van een FTP-programma wat je gebruikt om de server te benaderen) met twee mapjes "router" zie ik een essentieel verschil met mijn situatie.
In jou situatie heb je in de map router een index.php bestandje + nog een map cgi-bin met daarin het index.html bestand.
Ik maak op dat niveau helemaal geen gebruik van php binnen de website. (Wel verderop in de website met een genealogy programma).
Er worden geen php-bestanden aangemaakt, geen cgi-bin map. Het index.html bestand staat bij mij meteen in de map "router".
Mogelijk zit daar dan het verschil in interpretatie dat er in jouw situatie eerst via een php-omweg, een niveau dieper wordt gegaan, om dan vervolgens alsnog een simpele html-code op te pakken als verwijzing. De discrepantie zit hem dan mogelijk in het gebruik van php.
Probeer eens, het index.html bestand rechtstreeks in de map router te zetten, en het index.php bestandje even te hernoemen met een andere prefix zodat het niet gebruikt wordt. Wat levert dat op?
Hier mijn situatie:
Het .htaccess bestandje heb ik gekopieerd vanuit mijn andere domein waarop CPanel draait.
EDIT: de scherm-afdruk is abusievelijk gemaakt met het domein waarop CPanel draait, niet DirectAdmin.
Die maakt nog zo'n extra .htaccess bestandje, met een aantal functies zoals eerder uitgelegd < HIER > (http://www.synology-forum.nl/synology-router/met-router-rsm-beveiligd-verbinden-%28-via-subdomein-%29/msg176218/#msg176218)
[attach=1]
-
In jou situatie heb je in de map router een index.php bestandje + nog een map cgi-bin met daarin het index.html bestand.
Dit is niet zo. In de map "cgi-bin" zit niks. Als ik op die map klik gebeurt er niks. Het index bestand zit volgens de ftp rechtstreeks in de map(pen) "router". Waarom er door Direct Admin ook 2 mappen "router"worden aangemaakt is mij niet duidelijk. Ook niet welke ik dan moet pakken om de redirect in te zetten, maar dat kan ik wel uitzoeken door t te proberen..
[attach=1]
-
Sorry, niet goed gekeken. Ik ben kennelijk even helemaal van de wap af. :o
Ik haal wat dingen door elkaar. De voorgaande schermafdruk in mijn vorige reactie is vanuit het domein met CPanel. :oops:
Binnen DirectAdmin (het andere domein) heb ik enkel dat index.html bestandje.
Waarom het bij jou dan niet werkt, heb ik verder geen verklaring voor.
Misschien een andere versie van DirectAdmin (versie gebruikt door mijn ISP 1.44.3 ) ??
[attachimg=1]
-
Bij dit soort getest met aanpassingen in DNS gegevens, loop je ook regelmatig tegen cache gegevens aan. Dus de dns is wel goed veranderd, maar de browser of het OS gebruikt nog de oude instellingen.
Bij Safari heb ik het al gehad dat geen van mijn aanpassingen leek te werken, totdat ik de cache uitschakelde in het 'ontwikkelmenu'. Een menu dat standaard niet zichtaar is. Andere browsers ken ik niet goed, maar daar zal iets dergelijks ook spelen.
-
In mijn geval heb ik het vanuit verschillende locaties werkend (met verschillende PC's ---> ik ben nu niet thuis) + idem met smartphone 3G. Misschien een optie voor @ddewit om te kijken wat een smartphone of tablet doet.
-
Ja. Ik heb cach dns van Chrome net geleegd.
Hier wat data van de server
[attach=1]
-
Dat is allemaal wat nieuwer aan updates.
Is het misschien een idee om dat privé hier te checken door gegevens hier in te vullen op mijn server van je domein, of ik dan wel bij jou uitkom?
Zouden we daarover beter via een PB daarover kunnen communiceren.
-
Ik heb de index.html file aangepast met een doorverwijzing naar nu.nl.
Als eerste:
is opvallende dat Direct Admin blijkbaar die index.html lopieert in beide mappen.
Als ik 'm dus wijzig in: /domains/domainnaam/public_html/router/index.html dan veranderd die 'm ook in /public_html/router/index.html
dan: ik heb de redirect nu gezet naar nu.nl en in Firefox en Edge werkt dit prima,
[attach=4]
[attach=3]
maar in Chrome blijft die maar naar die foutmelding verwijzen. Ik heb de DNS geflushed met ipconfig /flushdns en in Chrome via chrome://net-internals/#dns cleard dnsen bij de sockets close idle sockets en flush spocket pool, maar Chrome blijft error message geven terwijl die naar nu.nl moet verwijzen
[attach=5]
-
Nou ja, ik gebruik geen Chrome.
(Na een blauwe maandag enkele jaren terug meteen er weer afgehaald, nooit meer opnieuw geïnstalleerd).
Kan daar verder niets zinnigs over zeggen.
Misschien is het een optie om doorverwijzingen alleen in een .htaccess bestandje op te nemen?
Daar zijn ook mogelijkheden in te maken. (hits via Google (https://www.google.nl/?gws_rd=ssl#newwindow=1&q=.htaccess+redirect))
-
Alsje eenmaal met de inline plaatje aan de haal gaat dan is het niet makkelijk /onduidelijk hoe ze goed te krijgen.
In het algemeen ben ik tevreden over Chrome, mbt dit dns ding niet.
-
Ik heb Chrome even geïnstalleerd om te testen. Krijg in dat geval dezelfde foutmelding als wat jij ervaart. Kom er niet in verder.
Ook Opera getest, en heeft een vergelijkbaar probleem. Ook daarmee kom je er niet in verder.
OOK zonder een rederict en rechtstreeks met https en WAN IP-adres ingegeven.
Alleen Firefox en Microsoft Internet Explorer hebben een work around om het zelf ondertekende certificaat op te slaan en/of door te gaan.
De standaard apps op mijn smartphone (met een verouderde Android versie) hebben ook geen problemen.
Met Microsoft Edge geen ervaring (heb geen PC met Windows 10 erop).
Aanvulling:
Heb nu wat uitgebreider gegevens in het zelfondertekend certificaat ingevuld.
De webbrowser Opera geeft nu wel de mogelijkheid door te gaan, Chrome nog steeds niet.
-
mmm.
kijken of het met .srv bestand kan zoals @Ds211 schreef. Wellicht kun je me wat op weg helpen Ds211 daar ik totaal geen ervaring heb met srv bestanden.
[attach=1]
ik heb een A record aangemaakt als in router.domeinnaam.nl en deze verwezen naar de Wan Ip van de Synology router..
-
Dat chrome moeilijk doet kan ook aan het certificaat liggen. Als ik op de nas inlog (met een self-signed certificaat met SHA-256) dan krijg ik gewoon een groen slotje. Als ik op mijn foscam IP camera inlog, weigert hij het certificaat te vertrouwen en krijg ik steeds een melding met strepen door 'https'. Ook dat certificaat is netjes geïmporteerd maar gebruikt de oude SHA-1 handtekening. Volgens is Google gestopt om die als vertrouwd aan te merken.
qua srv bestanden. Ik vraag me af of dat kan werken. Jij wilt nml ook het protocol veranderen van http -> https als ik het goed begreep. Het je de index file die ik aangaf al gebruikt. Voor mij werkt die al tijden perfect. Doet hetzelfde als de versie van Luc, maar heeft nor een paar backup mechanismen voor het geval de redirect moeilijk doet.
-
Ik heb een (gratis) certificaat van startssl. Deze werkt op basis van domein en sundomein. Op de NAS op de studio gaat dit prima. Ik kom aan vanuit de subdomein omzetting vanuit het DNS (nas.domeinnaam.nl > wan ip nas) bij de NAS,deze wordt via de virtuele host op de NAS verwezen naar een map met daarin een index.html bestand met een redirect naar https://nas.domeinnaam.nl:5001/webman/index.cgi. Zolang ik die subdomeinnaam in de adresbalk hou gaat het goed. Krijg ik ook groen slotje. Met ipnummers werkt het wel (in alle browsers) maar niet een groen slotje (en melding niet kloppend certificaat).Das ook logisch want het certificaat dekt alleen die (sub)domein.
Omdat de router geen omzetting via een virtuele host ondersteund (webserver) en mijn DNS bij mijn hosting provider geen doorsturing naar Ip mét poort nummer ondersteund probeer ik het bij de Synology Router door in DirectAdmin een subdomein aan te maken en dan daar het index bestand aan te passen,alleenin dit geval lukt het me niet om in Chrome de DNS te legen waardoor hij een foutmelding blijft geven ondanks dat het index.html bestand allang naar een andere site verwijst..In firefox en in Edge werkte het dus wel,maar in Chrome kan ik t niet meer testen..
Ik zou ook graag welwillen begrijpen wat er anders is als een subdomein aanmaken in DA en deze via een indexbestand doorsturen dan het via de DNS en dan virtuelehost en dan doorsturen doen is..
En ja ik wil graag het protocol veranderen, altijd een beveiligde verbinding maken..
-
Wat een gehannes met bestandje hier en een redirect daar.
Overweeg een proxy/gateway :
http://responsive.2kool4u.net/tech/proxy/
Dan hoef je van buitenaf geen portnummer te gebruiken. Https op port 443 is dan voldoende.
Je gebruikt dan bijvoorbeeld als url : https://dsm.domainnaam.nl
En intern op de NAS wordt verbinding gemaakt naar port 5000/5001.
-
Gehannes is het wel ja. Als ik gewoon in de DNS van de hosting provider een poort mee kon geven was het ook zo opgelost.
Een proxy draaien kan dat ook op de Synology router dan? Namelijk dat is wat ik wil via een subdomein een beveiligde verbinding met de router opzetten.
-
Dan hoef je van buitenaf geen portnummer te gebruiken. Https op port 443 is dan voldoende.
Je gebruikt dan bijvoorbeeld als url : https://dsm.domainnaam.nl
Ik vraag me af of dat wel met poort 443 te maken heeft?
Datzelfde subdomein wat jij als voorbeeld geeft, geeft met Chrome juist die foutmelding, je komt er dan niet mee verder.
Er komt in die redirect helemaal geen poortnummer voor, hooguit achter de schermen 443 omdat het om een beveiligde verbinding gaat.
Nu snap ik wel dat het maar als "een voorbeeld" en schrijfwijze in die uitleg was bedoeld, maar het is toevallig wel een werkende link,
die bovendien aantoont dat je beredenatie niet juist is. :o
Met Firefox, Internet Explorer, Opera kun je in dat geval toch doorgaan, en kom je in dit voorbeeld aan een werkelijke website.
-
Chrome geeft geen foutmelding als je via een IP nummer inlogt, zolang het maar een goed certificaat is en je hem als betrouwbaar ingesteld hebt:
[attachimg=1]
Ik gebruik ook een self-signed certificaat die ik zelf aanmaak. In Chrome kun je gewoon aangeven dat het IP nummer, of een subdomein, te vertrouwen is. Het gaat pas mis met onbetrouwbare certificaten. En hier legt Chrome de lat steeds hoger. Vorig jaar mocht je nog SHA-1 certificaten gebruiken, maar nu kun je die niet meer als betrouwbaar aanmerken. Ik ben lang bezig geweest om dat toch voor elkaar te krijgen bij mijn IP camera met ingebakken certificaat, maar SHA-1 vertrouwd te maken lukt me echt niet meer bij Chrome, ook al staat hij tussen de certificaten.
Ik lees echter nergens met wat voor certificaat jullie dat getest hebben.
-
Ik lees echter nergens met wat voor certificaat jullie dat getest hebben.
Getest met 512 bits (64 bytes) - 1024 bits (128 bytes) - 2048 bits (256 bytes) = standaard - 4096 bits (512 bytes)
Ik zal het nu eens gaan testen met IP-adressen.
-
Met alle veiligheidsrisico's voor lief nemend
Die zijn niet anders dan wat men hier probeert ;)
-
Babylonia, ik bedoel niet de sleutellengte, maar het gebruikte handtekening algoritme. Zie ook: Google+Chrome+gaat+support+van+SHA-1-algoritme+afbouwen (https://www.security.nl/posting/401149/Google+Chrome+gaat+support+van+SHA-1-algoritme+afbouwen). Daar doet Chrome moeilijk over als dat op SHA-1 staat. Mijn foscam camera heeft b.v. een 2048-bits certificaat met SHA-1.
Safari op de Mac laat sha1 nog wel toe, maar ook daar kun je al in het ontwikkelmenu instellen om deze certificaten niet meer met een slotje af te beelden.
-
Als men de info van een certificaat bekijkt, zit er zowel een SHA-256 "vingerafdruk" bij, alsook een SHA-1 "vingerafdruk".
(Rechts van het plaatje maar hieronder niet afgebeeld de certificaatgegevens).
[attachimg=3]
Hoe die SHA-1 "vingerafdruk" uit te schakelen of niet te gebruiken is me echter onduidelijk.
Er zijn geen aparte functies om dat in te stellen.
De menu's, (met even de voorbedrukte voorbeelden gebruikt):
Het 1e menu:
[attachimg=1]
Als dat is ingevuld en men verder gaat, komen in het volgende menu er twee regels bij, waar men naar ik begrijp de IP-adressen of DNS domeinnaam vastlegt. (Onderste regel evt. subdomeinen / aliassen).
[attachimg=2]
Opvallend is wel dat in het hoofdmenu waar men die certificaten instelt, bij de Synology router er niet wordt aangegeven welk handtekeningen algoritme wordt gebruikt. Bij een Synology NAS (DSM 5.2 op een DS415+) juist expliciet info wordt gegeven dat SHA-256 wordt gebruikt.
Echter als ik het gebruikte certificaat van de NAS opklik in het begin van de browserregel en de informatie bekijk, wordt ook daar vergelijkbare informatie getoond zoals helemaal bovenaan in dit bericht. Dus zowel gegevens achter SHA-256 alsook achter SHA-1 vingerafdruk.
Overigens in Crome geeft bij mij de IP van de NAS eveneens dezelfde foutmelding, en kom ik er niet in verder.
-
Weet niet veel van certificaten i.c.m. webserver/browser maar zoals @Briolet al zei gaat het om het handtekenings algoritme.
De fingerprint is een hash van het hele certificaat.
Het standaard handtekenings algoritme van Synology is SHA256 (sinds ik dacht DSM 5.2).
Onder SHA2 vallen: SHA224, SHA256, SHA384 en SHA512.
-
Waarschijnlijk heb ik het toch mis dat het aan de handtekening moet liggen. Als ik nml via mijn WAN IP inlog op mijn nas, krijg ik het groene slotje ook niet voor elkaar. Blijkbaar werkt mijn multi-domein certificaat toch beter dan ik dacht. Ik heb er mijn domen in staan, maar ook alle subdomeinen via een wildcard, mijn synology naam en mijn interne IP. Inloggen via een van deze 4 namen geeft een groen slotje, via het wan-IP echter niet. Ook mijn 2e nas krijgt geen groen slotje als ik hem via zijn IP benader omdat dat IP ook niet in het certificaat staat.
Ik dacht dat het multi-domein deel nog niet goed werkte en iets miste omdat ik bij andere browsers nog steeds bij de eerste keer een toestemming moest geven. Chrome reageert er echter wel goed op.
NB het zelf maken van zo'n certificaat die meerdere domeinen en IP's beschermt, heb ik elders (http://www.synology-forum.nl/algemeen/maak-je-eigen-multie-domein-ssl-certificaat/) op deze site eens beschreven.
-
kijken of het met .srv bestand kan zoals @Ds211 schreef. Wellicht kun je me wat op weg helpen Ds211 daar ik totaal geen ervaring heb met srv bestanden.
ik heb een A record aangemaakt als in router.domeinnaam.nl en deze verwezen naar de Wan Ip van de Synology router..
nou zal eerlijk zijn maar ik heb een stomme fout gemaakt
srv is alleen voor applicaties zoals bericht systemen telefonie en bv spellen en niet voor http heb gisteren even een sub aangemaakt met srv en werkt idd niet
-
Bij fxw (mijn hosting provider incl dns) kan dus niet in de dns forwarden naar ip mét poort maar wel een forward instellen naar ip met poort via een dns forward server. Dit kan cloaked dus dat werkt.
-
Met betrekking tot die certificaten waar @Briolet eerder naar verwijst (http://www.synology-forum.nl/algemeen/maak-je-eigen-multie-domein-ssl-certificaat/msg128564).
In dat draadje, onderste reactie (http://www.synology-forum.nl/algemeen/maak-je-eigen-multie-domein-ssl-certificaat/msg143774/#msg143774) heeft iemand een certificaat gekocht voor weinig.
Ik heb even bij mijn web hosting-provider (https://www.neostrada.nl/ssl-certificaten.html) gekeken, en kom als goedkoopste optie aan een "domein-validatie" voor net geen Euro p/maand.
Als ik een domein en cerificaat laat koppelen aan mijn eigen thuis WAN IP-adres, waarachter router en nas zitten, is dat mogelijk ook een optie.
(Moet het dan nog wel even bij de provider verifiëren of het als zodanig werkt zoals ik in gedachte heb).
-
Misschien mis ik iets maar je kunt voor 1 domein met 1 subdomein een gratis jaarlijks certificaat maken hier:
https://www.startssl.com/?app=39
Hoe het werkt (handleiding) staat hier:
http://blog.mobile-harddisk.nl/tutorials/installatie-geldig-beveiligingscertificaat-op-synology-nas/
Werkt prima zolang je de (sub)domeinnaam in de adresbalk hebt.
-
Bij fxw (mijn hosting provider incl dns) kan dus niet in de dns forwarden naar ip mét poort maar wel een forward instellen naar ip met poort via een dns forward server. Dit kan cloaked dus dat werkt.
Dit kan volgens mij wel....
In je domein menu zie je rechts onderaan beheer forwards en in het forward menu kun je url forwarding kiezen dacht ik.
Hier kun je dan een 301, 302 of frame forwarding instellen en deze laten verwijzen naar een url met poort.
bv: router.joudomein.nl laten doorsturen naar https://login.joudomein.nl:5001
Je maakt eerst een A record aan van het subdomein 'login' en verwijst dat naar jou publiek IP adres
Dan dus een forwarder van router.joudomein.nl ---> https://login.joudomein.nl:5001
Je kunt echter NIET van router.xxxx.xx naar https://router.xxxx.xx:port verwijzen, dit zou in een infinity loop resulteren.
Als het goed is zal dit binnen 24uur werken.
-
@B3rt
Ja klopt dat dit kan, dat schrijf ik ook. Het kan niet rechtstreeks in de DNS maar wel met de domein forward fuctie.
Hoewel ik zelf nog geen poort kan meegeven. Ik krijg dan een error:
Fout
Het url [ip]:8001 is onjuist.
maar FXW zelf kan het wel instellen. Zal morgen f vragen hoe ik het kan doen, en ook hoe ik de door hen aangemaakt forwards mét poort kan editten (namelijk die functie is er niet).
BTW zoals ik nu in het DNS zie moet je je A record niet wijzen naar je ip, maar naar de Forwardserver van FXW (85.92.140.136)
[attach=1]
[attach=2]
[attach=3]
-
dat klopt, alleen je kunt niet forwarden naar jezelf want die forward server is je subdomein en die forward dan weer naar zichzelf alleen op een andere poort........
dwz
router.xxxx.xx forwarden naar router.xxx.xx:port kan niet
wel:
login.xxxxx.xxx forwarden naar router.xxxx.xx:port
Maar je hebt gelijk dat het via de interface niet kan, fxw zelf heeft inderdaad veel meer opties en daarmee kan het wel.
Of ze het doen is een andere vraag want wat jij wil is eigenlijk helemaal geen DNS functionaliteit maar iets wat ze zelf gemaakt hebben, kan me voorstellen dat ze dat zo min mogelijk willen (mis)gebruiken etc..
Het antwoord wat ze gaven dat je via de DNS niet kan port forwarden klopt wel..
Ik heb het zelf veel anders opgelost (heb ook fxw dns), heb het via een .htaccess redirect gedaan zoals eerder omschreven.
Je hebt hetzelfde als ik, deze router en synology nas toch?
Ik heb het volgende gedaan:
activeer de webservice op je nas en maak een subdomein aan en forward poort 80 en 443 naar je NAS:
Maak aan op de NAS
router.joudomein.nl verwijs deze naar mapje en de 'web' directory 'router' bv
In dat mapje zet je een .htaccess bestand met de code:
Redirect 302 / https://router.joudomein.nl:8001
Wat gebeurd er, je geeft de url in de browser https://router.joudomein.nl deze wordt geforward naar je NAS, daar komt ie uit in dat router mapje en apache voert het .htaccess bestand uit en redirect de bezoeker naar de url in de .htaccess
Daar het dezelfde url is kom je ook weer bij jou uit echter zet je browser er nu zelf 8001 achter en dan pakt je router hem op ipv de NAS
Heb je een andere poort dan wijzig je dat gewoon.
Dit kan je ook doen voor DSM mits je een andere subdomein gebruikt.
bv voor de router:
router.mijndomein.nl
en nas:
nas.mijndomein.nl
Voor beide maak je een (sub) domein aan in je NAS en zet je in een apart mapje met ieder zijn eigen .htaccess
Dit werkt perfect, gebruik dit al jaren zo....
In de DNS verwijs je alle A records naar je huis IP (moet je wel vast IP hebben) of via een cname naar je dyndns naam, als je subdomein eenmaal op jou publiek IP uitkomt en je router is ingesteld voor forwarding zal dit perfect werken...
Succes!
-
Methode met een .htaccess heb ik al eerder op gewezen (http://www.synology-forum.nl/synology-router/met-router-rsm-beveiligd-verbinden-%28-via-subdomein-%29/msg176496/#msg176496), maar nog niet zelf uitgeprobeerd.
EDIT:
Inmiddels uitgeprobeerd.
Heeft hetzelfde effect als de eerder besproken methode met een redirect in een index.html bestand.
-
ok thx.
maar dat is dus ongeveer hetzelfde als in de draad al besproken wordt. zie topic start
Ik heb dat eerder gemaakt voor mijn NAS via de beschrijving van Luke Vredeveld http://www.lukevredeveld.nl/wordpress/?p=234 maar in de RSM zie ik geen mogelijkheid om de virtuele server aan te maken en daar de doorwijzing naar de poort (8000 of 8001) goed te zetten.
"
of hier:
Ik doe het via virtal hosts, waar het volgende index bestand in staat:
Een nadeel is dat je dus afhankelijk bent van 2 apparaten. stel je nas staat uit; dan werkt het niet meer.
En kan dit ook cloaked, zodat de (sub)domeinnaam in de adresbalk blijft staan? Dit i.v.m. certficaten / beveiligde verbinding.
Weet iemand of je met een DNS van Synology (die dus ook op de router draait) wel kan verwijzen naar een ip mét poort?
-
ja ok, maar dan ga je denk ik voorbij aan het doel van een NAS...
De bedoeling is juist dat een NAS altijd aanstaat en bereikbaar is voor elk apparaat in je netwerk, als die NAS crashed kun je de router altijd nog bereiken door direct op poort te verbinden. Je wilt toch ook niet jan en alleman toegang gaan geven op je router toch?
Dus de login/forwarding naar je router is voornamelijk voor jezelf bedoeld, hoe groot is de kans nu dat je NAS geheel onbereikbaar is (of zet jij heb echt ooit uit?), hoe vaak is dit al gebeurd sinds je het apparaat hebt? Zo groot is die kans dus.... :)
-
Ik denk dat het heel persoonlijk is, met wat je met een NAS doet. De NAS hier staat eerlijk gezegd meer uit dan aan.
Bij het exemplaar 35 km verderop staat die alleen overdag aan.
De NAS hier wordt gebruikt als een "archief" van data. Daar hoeft niet elk moment van de dag op worden terug gegrepen.
Er gaan dagen voorbij dat de NAS helemaal niet wordt benaderd. Hoeft die ook niet aan te staan.
-
Methode met een .htaccess heb ik al eerder op gewezen (http://www.synology-forum.nl/synology-router/met-router-rsm-beveiligd-verbinden-%28-via-subdomein-%29/msg176496/#msg176496), maar nog niet zelf uitgeprobeerd.
EDIT:
Inmiddels uitgeprobeerd.
Heeft hetzelfde effect als de eerder besproken methode met een redirect in een index.html bestand.
Er zit wel een verschil tussen redirect en .htaccess, het redirecten via .htaccess is veel sneller en ook betrouwbaarder.
Code technisch is het absoluut aan te bevelen dit te doen via een mod_rewrite dus (.htaccess)
Nog een andere methode is om PHP te gebruiken om te redirecten in een index.php bestand.
Voordeeltje wat dit extra bied is dat je zelf parameters of filters kunt maken en dan daarop een specifieke redirect laten uitvoeren.
Bv ip X of interne redirect je naar http en andere naar https....
Of je wilt bijhouden wie allemaal een redirect doet etc, je moet dus een beetje kunnen scripten...
Maar PHP heeft voor een eenvoudige redirect geen meerwaarde, ik zou dus voor de mod_rewrite (.htaccess) gaan.
-
En dan (ook) nog; wat voor de mensen die geen NAS hebben maar wel de router?
Waarom kan het niet direct vanuit een DNS, fowarden naar ip met poort?
-
simpel als je niets hebt draaien erachter waarop je normaal web verkeer nodig hebt, verander de SRM poorten in 80 en 443..
Geen idee trouwens of de router dit accepteert, maar indien wel dan connect je direct op domeinnaam zonder poort toevoeging naar de router.
-
Tuurlijk draaen er tegenwoordig wel dingen achter een router, bijv.: pc's , tv's, imac's, macbooks, etc..
Ik zou graag een zo efficient mogelijk oplosing hebben. Die via een virtual host - index / .htaccess kan, maar vereist meerder apparaten met dus ook meerdere verbindingen en ook meer energie (ook verbruik).
Waarom kan zoiets niet direct vanuit een DNS, verwijzen naar een ip mét poort?
-
Efficient en in 1 minuut werkend :
http://responsive.2kool4u.net/tech/proxy/
En DNS heeft geen weet van porten.
-
Waarom kan zoiets niet direct vanuit een DNS, verwijzen naar een ip mét poort?
Omdat DNS geheel niet met poorten werkt, dus ALLE dnsservers werken niet met poorten, dit heeft niet met je provider te maken.
Een DNS is een omzetting van naam naar een IP, poorten zijn weer iets van een apparaat en derhalve dien je dat daar ook te doen.
Nu hebben sommige aanbieders zelf tooltjes ontwikkeld voor consumenten om te redirecten naar poorten, echter dit is dus niet volgens de DNS standaard, daarin kan dit niet. (ik heb het over web redirects, niet applicaties zoals sip etc)
Wil je dus redirecten naar een specifieke poort zul je dit buiten de DNS om moeten doen of DNS panel die een los staand tooltje heeft of 3th party oplossingen.
Dat is eenmaal hoe dns werkt, daar kan je niets aan veranderen.
-
@Wyodor voor zover ik zie draait een proxy niet op de router, dus heb ik weer een ander apparaat nodig (nas)?
@B3rt helder. fijn dat ik dat nu kan vergeten, bedankt voor de uitleg!
-
Efficient en in 1 minuut werkend :
http://responsive.2kool4u.net/tech/proxy/
Wat ik lees moet je via die methode een web-server hebben draaien.
Vooralsnog is er geen web-server package voor een Synology router, dus blijft je met een redirect via een web- server die je elders (of op een NAS) hebt draaien.
Er zit wel een verschil tussen redirect en .htaccess, het redirecten via .htaccess is veel sneller en ook betrouwbaarder.
Code technisch is het absoluut aan te bevelen dit te doen via een mod_rewrite dus (.htaccess)
Ik heb beide methodes geprobeerd, merk geen verschil in die twee methoden qua snelheid. Zelfs eerder het idee dat via de index.html methode net een betere respons heeft. In ieder geval is het verschil zodanig miniem, dat de gemiddelde gebruiker daar niets van zal opmerken.
Of het veiliger is, daar heb ik mijn vraagtekens bij. De code die je bij html wel makkelijker zou kunnen uitlezen, beschrijft dezelfde redirect data als een .htaccess bestandje die je niet zou kunnen uitlezen. Maar eenmaal doorgestuurd, zie je in de adresregel van een browser waar je naar toe bent doorgestuurd. Dus geheim is de opgenomen code geenszins.
Alleen opties die je beschijft met gebruikmaking van PHP is dan misschien interessant voor degene die wat in scripting doet.
-
Die proxy draait op dezelfde webserver waar je dat htaccess bestand of index.html/php hebt staan.
PS. ik gebruik de oplossing om toegang te krijgen tot de KPN experiabox.
Zoals ik al zei : 1 minuut werk.
-
Dan kan je dus ook de andere methode's gebruiken.
Het ging er nu nog om wat als je GEEN nas of webserver hebt draaien in je LAN.
Mijn stelling is dan, zet je router poorten gewoon op poort 80(http) en 443(https) want je hebt toch een webserver die deze nodig heeft.
Heb je wel een webserver draaien, dan kan je ook de verschillende redirects methodes of de proxy methode gebruiken.
Maargoed voor al deze opties heb je dus wel een server/nas nodig die 24/7 aanwezig is, bij mij staat de nas altijd aan dus is dat geen probleem.
Blijkbaar zijn er mensen die de NAS uitzetten en daar werkt dit dan niet voor, vandaar zocht men dus nog naar een oplossing zonder webserver/nas.
edit:
wat ik wel vreemd vind is dat er geen webserver packages zijn voor de RSM, wel is er DNS, RADIUS etc beschikbaar maar weer geen web. Ik heb in een ander topic al eens gevraagd of er geen 3th party repo's voor RSM zijn net als voor de DSM, wellicht deze via 3th party zijn toe tevoegen en je zo een lichte web/redirect server akn draaien op je router.
-
Eerder heb ik bij Synology wel een verzoek ingediend om een eenvoudige web-server als package op te nemen voor SRM.
Iemand anders is wel aan het stoeien geweest met third party packages:
http://www.synology-forum.nl/synology-router/entware-installeren-op-srm-1-0/
Kijk je dan bij de beschikbare pakketten, zit er ook een Apache web-server bij:
http://qnapware.zyxmon.org/binaries-arm/Packages.html
Maar dan moet je nogal wat rommelen in de root van de SRM software.
Zelf heb ik nog 3 websites bij een hostingprovider ondergebracht. Kan daar dus wel mee vooruit.
-
maar er is dus nog geen repo die je kan toevoegen in SRM instellingen zoals in DSM en kan kijken wat er al is?
-
Misschien mis ik iets maar je kunt voor 1 domein met 1 subdomein een gratis jaarlijks certificaat maken hier:
https://www.startssl.com/?app=39
Hoe het werkt (handleiding) staat hier:
http://blog.mobile-harddisk.nl/tutorials/installatie-geldig-beveiligingscertificaat-op-synology-nas/
Inmiddels heb ik een nl-domein voor mijn WAN IP-adres, en wilde zo'n gratis SSL certificaat aanvragen.
In het nieuwe jaar is nu net die website vernieuwd, en er zijn wellicht wat aanpassingen in de wijze van afhandeling met die certificaten.
Ondanks die nieuwe schermen kom ik telkens wel stappen verder, maar uiteindelijk loop ik vast op het onderstaande,
waarbij achter het met rood afgeschermde deel mijn nieuwe domeinnaam staat.
Het betreft dus vast voorgeprogrammeerde e-mail adressen voor verificatie.
[attach=1]
Ik heb dan wel een domeinnaam voor mijn WAN IP-adres, maar heb verder geen e-mail-box geïnstalleerd op mijn NAS die specifiek van dat nieuwe domein gebruik zou maken. Was ik eerlijk gezegd ook niet van plan om te installeren voor zo'n enkele mail die je verder niet gebruikt.
Het gaat me enkel om een domein voor mijn WAN IP-adres.
Is er geen manier om in de interface van mijn domeinnaam account bij DNS een verwijzing of redirect voor email in te stellen die naar mijn "normaal" gebruikte e-mailbox verwijst (wat dus een ander domein betreft)?
-
ben bang dat je daar niet onderuit komt om een van die 3 aan te maken want dat bewijst nl voor hun dat jij gemachtigd bent voor dat domein en dat je webmaster@nieuwdomein redirect naar webmaster@ouddomein zou hun worst zijn
-
Er wordt eenmalig een email naar dat adres gestuurd (daarmee valideren ze het domein) met een verificatie link. Das dus ook de enige keer dat je m nodig hebt. Wanneer jij er dus voor kan zorgen dat dat mailadres wordt geforward en je kunt op die verificatielink klikken dan is t goed.
-
Btw zou tof zijn als je meteen een nieuwe beschrijving maakt van hoe zo'n gratis certificaat te krijgen via de nieuwe site..
-
Toevallig heb ik deze week nog geprobeerd via deze site een nieuw certificaat aan te maken. Iets wat ik elk jaar in januari doe omdat ze maar een jaar geldig zijn. Ik kwam er niet doorheen, omdat er helemaal geen mails van startssl.com binnenkwamen. Mail gestuurd, ook geen reactie.
Heb uiteindelijk maar ergens anders een betaald certificaat genomen voor twee tientjes. Is meteen 3 jaar geldig, dus kan nu even vooruit. En de procedure was een stuk simpeler omdat ze de CSR van Synology ondersteunen.
-
ben bang dat je daar niet onderuit komt om een van die 3 aan te maken want dat bewijst nl voor hun dat jij gemachtigd bent voor dat domein en dat je webmaster@nieuwdomein redirect naar webmaster@ouddomein zou hun worst zijn
Daar kan ik me wel iets bij voorstellen, maar ben bij hen op mijn persoonmlijke account geregistreerd op mijn normale e-mail waarvan dat domein een deel is van mijn nieuwe domeinnaam. (Het nieuwe domein is enkel met een aanvulling).
Maar goed, ik heb een support mailtje gestuurd. Kijken wat daar uit komt.
@ddewit
Redirecten gaat niet, omdat het er juist om gaat om vanuit "dat nieuwe domein" een redirect te moeten maken naar het oude domein.
Moet je dus wel eerst alles instellen voor dat nieuwe domein om aan een redirect te kunnen toekomen.
Het zou aardig zijn als je gewoon een e-mail zou kunnen krijgen op het e-mail adres waarmee je daar een account hebt aangemaakt.
-
dat probleem had ik ook gewoon nog een paar keer geklikt ze hebben nl meerdere mailservers en volgens mijn logs kwamen niet voorbij mijn beveiligingscriteria maar de 3e mailserver van hun kwam er wel doorheen en kon ik het gewoon bevestigen
voor mijn andere domeinen heb ik ook betaalde certificaten en gaat idd een stuk simpeler
-
Ik heb van de week ook een betaalde gekocht EV validated (165,- 2 jr) en was ook wel te spreken over de service.. Maar goed gratis is gratis.. Die van die 2 tientjes voor 3 jaar kun je me vertellen waar dat was?
-
Het zou aardig zijn als je gewoon een e-mail zou kunnen krijgen op het e-mail adres waarmee je daar een account hebt aangemaakt.
Snap ik. Helaas ;(
-
ik heb ze gekocht bij xolphin voor 8 euro per jaar en voor multidomein voor 2 jaar is 28 euro
-
Dat was bij Xolphin.nl. Binnen een half uur geregeld. De prijs hangt natuurlijk ook van soort certificaat af.
-
Ik heb net bij mijn "gewone" provider waar ik een paar websites host, en waar ik ook mijn nieuwe WAN-IP domein heb geregistreerd (voor 2 jaar) ook maar een certificaat voor 2 jaar vastgelegd. Kost iets van ruim € 23,- (excl. BTW).
Moet nog geverifieerd worden (wellicht worden aangevraagd door de hostingprovider bij de betreffende instantie).
-
Ik ook bij Xolphin. Die zijn lekker bezig ;) Ik had een Ev Comodo validatie en die wordt dus ook naar admin@ oid. gestuurd..
@Babylonia dus je gaat de procedure op de nieuwe site van startssl nu niet afmaken (en documenteren)?
-
Inmiddels kreeg ik een mail dat de certificaten ter beschikking waren in mijn account bij de hostingprovider.
Ik kon die eenmalig binnenhalen. Alleen een beetje een vreemde methode.
Binnen een webvenster zag ik een hoop onleesbare tekst in delen samengesteld, vooraf gegaan met:
Eerste deel:
-----BEGIN CERTIFICATE-----
en eindigend met:
-----END CERTIFICATE-----
Dan nog 3 stuks vergelijkbare delen voorafgegaan met de tekst:
"Comodo PositiveSSL Bundle"
gevolgd door door 3x:
-----BEGIN CERTIFICATE-----
en eindigend met:
-----END CERTIFICATE-----
Dus feitelijk 4 deel-teksten die als certificaat gelden ?!
Die heb ik voor de zekerheid maar gekopieerd en in een tekstbestand gezet en opgeslagen.
Daarnaast was er nog een "key" om te downloaden. Bleek één bestand te zijn.
Blijk ik dus achteraf eigenlijk twee bestanden nodig te hebben, het "key-bestand" en een "certificaat" bestand.
Volgens mij moet ik die dan zelf even samenstellen vanuit die tekst die ik "gelukkig" heb gekopieerd en opgeslagen.
Als voorbeeld vanuit een "Open VPN" ca.crt bestand die ik in een tekst editor heb geopend bleek het een vergelijkbare "onleesbare" tekst-indeling te hebben, eveneens met "--begin certificate--" en "--end certificate--" die ik hiervoor dus ook ben tegengekomen.
Dus het lijkt me voor de hand liggend om dan die delen tekst "apart" weg te schrijven als certificaat en het bestand te benoemen als ca.crt
Maar welke van die 4 bestanden moet ik dan importeren in mijn Synology router, naast het key-bestand zelf ??
Of gelden een aantal varianten?
Misschien iemand die goed thuis is met die certificaten hoe te handelen?
-
Heb je hier wat aan (https://www.positivessl.com/cert-install.php) ?
-
En daar, service, is die Xolphin dus goed in:
https://www.sslcertificaten.nl/support/Handleidingen/
https://www.sslcertificaten.nl/support/Synology/ (https://www.sslcertificaten.nl/support/Synology/)
Bij direct admin moet je dus eerst dat die certificaat aanvraag met daaronder het certificaat ingeven in een apart veld. En dan in het root veld dat root certificaat met daaronder direct die 2 intermediates. Staat heel duidelijk in de handleidingen..
-
Binnen een webvenster zag ik een hoop onleesbare tekst in delen samengesteld, vooraf gegaan met:
Dat zullen de public key, de private key etc zijn. De andere 2 weet is zo niet, want die gebruik ik niet. Je moet ze als 4 tekstfiles bewaren en dan de goede files in de nas importeren. Een goede extensie geven helpt ook om de functie uit elkaar te houden.
-
Bedankt voor die info.
Ik ben maar begonnen met wat testen.
De 1e poging met het allereerste stuk tekst (van de vier delen) tussen:
-----BEGIN CERTIFICATE-----
en eindigend met:
-----END CERTIFICATE-----
weggeschreven als ca.crt
Het key-bestand was als bestand reeds gedownload.
Ingeladen bij het volgende scherm in de Synology router.
[attach=1]
En......
Het werkte meteen correct in zowel Firefox, Chrome, Opera met een sleuteltje / slotje aan begin van de URL adresregel.
Vergelijkbaar het certificaat in de NAS geïmporteerd, en ook die services werken nu correct zonder meldingen.
En ja, ik heb de verschillende stukjes tekstbestand keurig netjes benoemd / opgeslagen zodat ik weet welk stuk certificaat het behelst. ;)
[attach=2]
-
Normaalgesproken is het als volgt:
Bij persoonlijke key hoor je de server key in te vullen. Deze heb je normaalgesproken bij het maken van de aanvraag ook zelf gegenereerd. Hiermee kun je het certificaat ook opnieuw genereren.
Bij certificaat vul je het verkregen certificaat in, dat is uniek voor jouw domein.
Bij intermediair certificaat moet je de bovenliggende certificaten invullen. Dat zijn dus eigenlijk de certificaten waar jouw verkregen certificaat van afgeleid is. Als ze als aparte files zijn verstuurd moet je ze zelf bundelen tot één file.
[attachimg=1]
Je moet wel zorgen dat het intermediair certificaat wel compleet is, dus het volledige pad bevat. Anders krijg je bijvoorbeeld met OpenVPN problemen met certificering, omdat dan de geexporteerde configuratie niet volledig is (een deel van het certificatie-pad ontbreekt dan).
Overigens kun je bij de meeste SSL providers de files in verschillende uitvoeringen downloaden.