A probléma: olyan webcím-re is kiszolgál webszerverünk a https protokollon, amire nincs is tanúsítvány. Az eredmény: elégedetlen ügyfél, hogy miért az ő https címe alatt jön be más oldala (még akkor is, ha beszól a böngésző, hogy hiba van – mivel a tanúsítvány nem stimmel a domainhez). A megoldás könnyűnek tűnik. Nos, nem az. Elsőre.

Ha egy kicsit utána próbálunk járni, ki is derül, hogy miért lehet hibába futni. Alapvetően a legtöbb – népszerű – webszerver, mint az Apache httpd, és az Nginx alapkonfigurációjában nincs olyan opció, ami megmondja azt, hogy csak a felsorolt hostnevekre, domainekre szolgáltassanak.Ez pedig azt eredményezi, hogy azonos IP-n lévő szervereknél egy-egy domain el tud tévedni. Ez http protokollnál nem olyan nagy ügy és könnyen kivédhető, de a https sokkal összetettebb.

Egész sok időt el lehet tölteni a megoldás felkutatásával, ezért én szeretnék egy gyors és kipróbált technikát megosztani.

Nálam egy Nginx proxy áll az apache-ok előtt, tehát ez a példa Nginx-nél működik, természetesen akkor is, ha a teljes kiszolgálási láncot ez viszi.

A következő beállítást kell berakni valahogyan mindenhová, ahol a 443-as portra állítottunk be kiszolgálást, a server_name … után:

 
if ($host != $server_name) {
    rewrite ^(.*)$ http://$host permanent;
}

Ez a https://akarmi.com-ot átdobja http://-s verzióra, és nem engedi be más webcímre https alatt.

Fontos, hogy tényleg mindenhol ott legyen, ahol a 443-as portra állítunk be, mert különben átjut a kérés. Célszerű a fenti konfig-részt egy külön file-ba (pl.: no-ssl-redirect) tenni, majd simán inlcude-olni:

server {
    listen 443;
    server_name xxxx.hu;

    include /etc/nginx/sites-available/no-ssl-redirect;

    ssl on;
....

Ezzel meg is oldottuk. Nem az én találmányom, több megoldási kísérlet után találtam rá erre, ami működik is. Élesben letesztelve. 🙂

 

0.00 avg. rating (0% score) - 0 votes

Leave a comment

Az e-mail címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük