Probleem met HTTPS

[tobiastheebe]

Ik heb een aantal services op mijn router extern beschikbaar gemaakt middels port forwarding:

• Website (Nginx 1.6.2 op Raspberry Pi 3) op poort 80 en 443 (HTTP en HTTPS), voorzien van geldig SSL-certificaat;
• Webinterfaces twee IP-camera's op poort 8001 en 8002 (HTTP).

Naast bovenstaande services staan ook SSH en RDP open voor naar de Raspberry Pi, maar dat even terzijde.

Het publieke IP-adres van mijn router is gekoppeld aan de DDNS-service van Dyn, zodat ik alle services kan bereiken op mijn eigen domein, dat ik vanaf nu mijndomein.dyndns.org zal noemen.

Dit werkt grotendeels prima, maar ik heb één probleem:

Als ik naar mijn website ga (https://mijndomein.dyndns.org) dan kom ik zoals bedoeld op de beveiligde versie van de website die op mijn Raspberry Pi draait. Het SSL-certificaat wordt goed geladen. Ga ik vervolgens naar één van mijn IP-camera's op http://mijndomein.dyndns.org:8001 of http://mijndomein.dyndns.org:8002, dan probeert mijn browser deze webinterfaces elke keer via HTTPS te openen (wat dus niet beschikbaar is) en krijg ik de volgende foutmelding:



Ga ik naar http://mijndomein.dyndns.org:8001 of http://mijndomein.dyndns.org:8002 voor dat ik naar https://mijndomein.dyndns.org ga, dan is er geen probleem.

Om 8001 en 8002 weer normaal te kunnen openen, moet ik de browser opnieuw opstarten. Geschiedenis en cache leegmaken werkt niet.

Overigens kan ik beide nog wel bereiken op mijn publieke IP-adres of de door mijn ISP uitgedeelde DNS-naam. Alleen voor het DDNS-domein werkt het niet meer.

Het probleem doet zich voor op al mijn browsers (Firefox 46.0.1 (mijn primaire browser), IE 11 en Edge) en zowel op mijn eigen internetverbinding (Ziggo DOCSIS) als op de internetverbinding van mijn werk (XS4ALL ADSL). Ik gebruik Windows 10 Enterprise Version 1511 (x64).

Heeft iemand enig idee waardoor dit probleem veroorzaakt zou kunnen worden? Wellicht mijn router (Cisco EPC3928AD)?

 

[manamana]

Hallo. Ik ben er niet zo in thuis, maar kwam dit tegen het is slechts een tip met mogelijke oplossingen. Succes

https://www.sslcertificaten.nl/support/Foutmeldingen/Foutmelding_-_ssl_error_rx_record_too_long

 

[tobiastheebe]

Hoi manamana, het vreemde is dat de foutmelding niet optreedt op mijn server, maar op IP-camera's die niets met HTTPS te maken hebben noch ondersteunen. Desalniettemin bedankt voor de tip.

P.S.: Heb zojuist nog geprobeerd de proxyserver globaal volledig uit te schakelen (autodetectie is standaard), maar ook dit biedt geen soelaas.

 

[manamana]

Heb je die probleem wizard rechts in beeld gebruikt.

En anders misschien dit Forum waar de kenners zitten.

https://www.raspberrypi.org/forums/viewforum.php?f=88

 

[tobiastheebe]

Helaas is die niet op mijn probleem van toepassing.

 

[dnties]

Ik kan zelf slechts aan 2 mogelijkheden denken:
a. Een gepoogde redirect vanaf de ip-camera's naar een beveiligde versie van die zelfde ip-camera webpagina indien een host-header aan de webserver wordt doorgegeven vanaf de verbindende browser. Uiteraard weten we niet welke ip-camera's het over gaat, dus we draaien hier op het forum eens aan de schijf in de roulettebak.
b. De router doet aan poorttranslatie en je gebruikt die ook, dus je verbindt over poort 8001 extern niet naar poort 8001 van de ip-camera1, maar naar (bijv.) poort 80 van de ip-camera1. Oftewel: ip-camera1 luister niet op zijn eigen poort 8001 naar webverzoeken maar 'gewoon' op poort 80. We komen dan weer terug op het verhaal over redirect, maar dan in de sfeer dat op de ip-camera webpagina ook SSL links voorkomen waardoor je in de problemen komt. Ook hier weer het verhaal over host-header.

Samenvattend: Als ik 'warm' zit met bovenstaande (en dan moet haast wel, want op ip-adres werkt het goed), dan zouden instellingen op (de webserver-software van) de ip-camera's de schuldige moeten zijn.
Dit moet je trouwens kunnen testen door uit te zoeken hoe de navigatie werkt op de ip-camera's en die dan "naspelen" (zodra ingelogd op de ip-camera's) door zo'n navigatie-link te gebruiken in je webbrowser.
Kan in jouw geval makkelijk, want als je eerst de ip-camera's bezoekt en dan zo'n navigatie-link opslaat als snelkoppeling en test dat die goed werkt en (later) dan de werkwijze gebruikt die de problemen oplevert en dan de opgeslagen navigatie-link klikt en dat werkt wel, dan moet (in mijn ogen) het probleem wel aan de website van de ip-camera's liggen.

Tijs.

 

[tobiastheebe]

Hoi Tijs, ik gebruik een Panasonic BL-C111 (op poort 8001) en KX-HCM10CE (op poort 8002). Bij beide camera's draait de webinterface inderdaad op poort 80.

Ik heb net de configuratiepagina van de KX-HCM10CE opgeslagen als bladwijzer. Vervolgens naar de website gegaan op 443 en tenslotte weer terug gegaan naar de bladwijzer. Kreeg opnieuw de SSL-foutmelding.

 

[dnties]

Dan kunnen die 2 mogelijke oorzaken (wat mij betreft) niet de reden zijn dat het misloopt, dus die 2 mogelijke oorzaken zijn (wat mij betreft) uitgesloten als de oorzaak.
Vervelend is dan wel weer dat ik nu geen ideeën meer heb. Enige wat je nog kunt proberen is geschiedenis en cache legen tussen het raadplegen van je SSL website en de ip-camera's (wel gewoon de browser open houden). Als dat helpt/werkt geeft dat misschien iemand een idee wat er misgaat.

Tijs.

 

[tobiastheebe]

Enige wat je nog kunt proberen is geschiedenis en cache legen tussen het raadplegen van je SSL website en de ip-camera's (wel gewoon de browser open houden).

Net geprobeerd maar werkt helaas ook niet. Ik kan de IP-camera's in elk geval nog normaal bereiken op mijn publieke IP-adres en DNS (.dynamic.ziggo.nl).



In elk geval bedankt voor de hulp en de ideeën.