Safari 11 is strenger geworden met certificaten [waarschuwing]

[Briolet]

Ik wilde net inloggen op mijn nas via een bookmark. Daar stond echter een poortnummer achter en kwam dus mijn nas niet binnen. Of concreet:

Ik heb een certificaat voor het inloggen via "dsm.mijndomein.nl". Via de bookmark probeerde ik in te loggen via "dsm.mijndomein.nl:5001". Bij mijn specifieke opzet, ziet Safari dan een ander certificaat en bij oudere versies van Safari kreeg je dan de vraag of je dat certificaat wilt vertrouwen.

Nu kreeg ik echter het volgende scherm:



Er is nu helemaal geen optie meer om dat certificaat te vertrouwen. Leuk als je een automatische instelling hebt van http -> https en je stelt iets verkeerd in op je nas met de certificaten. Dan kun je het alleen nog oplossen met een reset van de nas.

Bij Safari 10 gebeurde dit ook al bij sommige certificaten die minder betrouwbaar opgebouwd waren. b.v. de ingebouwde  certificaten van mijn HikVision cameras. Safari 11 doet nu ook moeilijk bij een naam mismatch met certificaten van Let's Encrypt.

[Basalt]

Is hier een oplossing voor?
Ook binnen mijn LAN zou ik graag alleen HTTPS willen gebruiken, maar dat wordt zo wel lastig 

[Babylonia]

Bij mijn specifieke opzet, ziet Safari dan een ander certificaat....

Kun je dan niet beter die set-up zodanig wijzigen zodat slechts één certificaat geldig is, ongeacht welke poort of directory nog achter je domein volgt?
Zelf gebruik ik een commercieel SSL certificaat op mijn WAN IP.  Ongeacht wat er achter het domein volgt, werkt het dan.  Omdat ik zowel services benader rechtstreeks op mijn Synology router, als verder erachter op mijn NAS, heb ik hetzelfde certificaat daarbij dan geïmporteerd zowel in de router alsook in de NAS.

[Briolet]

Eén certificaat is geen optie doordat Synology slechts 256 tekens toelaat voor het geheel aan domeinnamen voor een Let's Encrypt certificaat. Ook de self-signed certificaten hebben die limiet, maar daar kun je wildcards gebruiken. (Ik heb daar in de beta fase van Let's Encrypt al een bugmelding over gedaan, maar Synology heeft er nooit iets mee gedaan)

Als je dus www.  smtp. dsm. smtp, mail, time, foto etc subdomeinen wilt gebruiken in combinatie met een wat langere domeinnaam, lukt het al snel niet meer op één certificaat. Ik had er twee nodig en heb er dan maar 3 van gemaakt, verdeeld naar toepassingen.

En nog een 4e voor OpenVPN omdat ik daar een self-signed exemplaar gebruik omdat de configuratie anders bij elke 3 maand ongeldig wordt als Let's Encrypt het certificaat vervangt.

Vanaf 2018 gaat Let's Encrypt ook wildcards toelaten. Ik denk dat ik dan eindelijk alles in één certificaat kan stoppen. Nu was ik verrast doordat je het certificaat per poort moet instellen. Achteraf logisch, maar ik had er nooit bij stilgestaan.

[Babylonia]

Dat zou dan mogelijk het verschil zijn met een commercieel aangeschaft SSL-certificaat wat ik gebruik??
Daar geldt voor een certificaat met een domeinnnaam, dat het tevens geldt met een wildcard   ''*"  erachter.
Het werkt bovendien ook met de  www.  extentie vóór een domeinnaam.

Maar ik vraag me af of een wildcard niet gewoon automatisch onderdeel uitmaakt van een certificaat?
Ik kan me nameijk niet voorstellen dat het zonder werkt. Daar is geen beginnen aan.
Als je een website hebt draaien op je NAS, heb je al snel extra aanvullingen achter een domeinnaam.
Denk aan php coderingen, of gewoon de eerste web-pagina indeling met  "/index.htm"  achter de domeinnaam. Dat zou dan allemaal niet meer werken !!
(Ook bij gebruik van Photo Station met alle aanvullingen achter de domeinnaam werkt het gewoon).

[Briolet]

Nee, de wildcard staat vóór het domeinnaam om alle subdomeinen toe te laten. Dus "*.mijndomein.nl".

Wildcards hebben het risico dat nu plots alles afgedekt is door het certificaat. Bij het starten van Let's Encrypt is daar een hele discussie over geweest en men vond het gebruik van wildcards te onveilig voor een automatische toekenning van een certificaat.

Nu wordt voor elke (sub)domeinnaam getest of die wel naar je nas leid. Bij een wildcard zijn er oneindig veel domeinnamen. Je kunt dan alleen testen of een random subdomein ook op je nas uitkomt omdat je niet weer welke subdomeinen in gebruik zijn. Maar dat houdt ook in dat je voor je domein zelf een wildcard moet aanmaken, zodat ook een random subdomein bij je nas uitkomt.

Let's Encrypt is nu om en volgend jaar worden de wildcards dus mogelijk. (Ik lees daar net in de link dat dit een nieuwe API vereist, dus Synology moet hiervoor ook iets updaten. Draft van de nieuwe Let's Encrypt API:  [ACME-v2]). Ik hoop eigenlijk dat ze bij een wildcard een standaard naam gaan testen zodat je die in je domein kunt zetten ter voorkoming dat je ook een wildcard subdomein moet gebruiken.

Een goed voorbeeld van een zeer uitgebreid wildcard certificaat is die van "google". Dat certificaat bevat over de honderd wildcard domeinen.

[Babylonia]

Nee, de wildcard staat vóór het domeinnaam om alle subdomeinen toe te laten. Dus "*.mijndomein.nl".

In mijn geval dus achter de domeinnaam, en niet ervoor.  (Bij de aanvraag heb ik niets extra ingevuld. Het werkte standaard als zodanig).
Maar ik maak dan ook geen gebruk van een "Let's Encrypt" certificaat.   (Kosten van dat commerciële certificaat iets van Euro 8,-  op jaarbasis).

[Briolet]

Geen idee wat dat is als het achter de domeinnaam staat. Een certificaat gaat alleen over de domeinnaam, en niet over de rest van het pad.

Ik heb intussen die draft van ACME-v2 eens doorgebladerd. Bij punt 8.5 gaat men in op het aantonen dat jij de eigenaar van het domein bent. Nu wordt er alleen gekeken of de DNS naar het domein bij de aanvrager wijst. In theorie kan je dan nog via een mit-aanval het verkeer omleiden en een certificaat voor een ander aanvragen.

In ACME-v2 moet je ook een speciale sleutel als TXT in je DNS record zetten.: "_acme-challenge.example.org. 300 IN TXT "gfj9Xq...Rg85nM"". Dat geeft nog meer zekerheid dat er alleen terechte certificaten uitgegeven worden. Maar dat vereist een compleet andere werkwijze bij de aanvraag en een andere GUI op de nas. Het zal dan best nog een tijdje kunnen duren voordat Synology dit implementeert en je een wildcard kunt aanvragen via DSM.

[Babylonia]

Geen idee wat dat is als het achter de domeinnaam staat. Een certificaat gaat alleen over de domeinnaam, en niet over de rest van het pad.

Dat klopt.  Verder over de materie nadenkend wilde ik daar nog een aanvulling op geven, (maar heb eerste een boterhammetje gegeten).
Zelf heb ik een NL-domein op mijn internet WAN IP-adres gekoppeld.
Bij de provider waar ik het NL-domein heb ondergebracht is het WAN IP-adres opgegeven, en is de aanvullende wildcard ingesteld.
Het certificaat behelst slechts de enkele domeinnaam.

Kan het nu niet controleren, want ben niet op mijn thuisadres, en heb niet de wachtwoorden bij de hand om in te loggen.
Maar is afhankelijk van ingestelde records (??), welke ingangen je kunt benutten.

Als dat bij "Let's  Encrypt allemaal niet mogelijk is, zou ik eens denken om dat op een vergelijkbare wijze af te handelen met een NL-domein, en SSL certificaat.
De kosten ervan zijn te overzien, en je zit niet met de rompslomp om dat  telkens drie maandelijks te moeten vernieuwen.

[Briolet]

Elke 3 maand vernieuwen is geen rompslomp omdat dit vanzelf gebeurd, zonder user actie. Het regelmatig updaten van certificaten is zelfs veiliger.   

Als er straks quantumcomputers zijn, is de verwachting dat de huidige SHA256 certificaten allemaal gekraakt kunnen worden. Ook het vergroten van de sleutellengte helpt niet veel tegen quantumcomputers. Bij de huidige computers gaat de benodigde rekenkracht exponentieel omhoog met de sleutellengte. Bij quantumcomputers zal dat lineair zijn.
Dus als je nu het onleesbare verkeer opslaat kun je het over 10 of 20 jaar alsnog bekijken. Hoe korter een certificaat geldig is, des te meer certificaten moet men kraken om alle informatie leesbaar te maken. Dus des te eerder men het achterwege zal laten.

Okay, ik moet toegeven dat jouw of mijn verkeer niet interessant genoeg zal zijn om langdurig op te slaan, maar als je een geheime dienst bent, moet je er wel rekening mee houden dat onderschept en bewaard verkeer, in de middellange toekomst wel gelezen kan worden.

Kan het nu niet controleren, want ben niet op mijn thuisadres,

Het certificaat met al zijn domeinnamen zie je toch al vóórdat je inlogt, mag ik hopen. 

[Babylonia]

Ik bedoel mijn gebruikers account bij de provider om de domeinnaam instellingen door te lopen, zodat ik verslag zou kunnen geven wat precies is ingesteld.