Witaj w NSSletterze - newsletterze dla przygotowujących się do certyfikacji Cisco CCNA, CCNP Enterprise oraz CWNA. Dzisiejszy mail ma 818 słów, a jego lektura zajmie Ci 4 minuty. 👀
Na początek ogłoszenie (i przypomnienie):
Dzisiaj o 19:00 zamykamy zapisy do naszego kursu CCNA. Wracamy dopiero na wiosnę. Odbierz swój dostęp teraz na https://szkolasieci.pl.
Czas leci.
🔎 Temat tygodnia
Zdarzyło Ci się pewnie nieraz zobaczyć czerwoną kłódkę w przeglądarce i komunikat, że "połączenie nie jest bezpieczne".
I raczej wiesz, że wynika to z faktu, że połączenie nie jest szyfrowane. I temat można by w sumie już zamknąć gdyby nie nietypowa sytuacja, w której błąd ten czasami się pojawia, a czasami nie.
Oto treść pytania podesłanego przez jednego z Czytelników:
"Istnieje strona internetowa https://ccie.pl. Podczas korzystania z adresu IP strony pojawia się komunikat "połączenie nie jest bezpieczne", ale dla nazwy domenowej wszystko działa poprawnie. Jaka jest najbardziej prawdopodobna przyczyna takiego zachowania? W jaki sposób można to naprawić?"
Pytanie zobrazowane jest grafiką:
Czuję się kompetentny żeby udzielić odpowiedzi bo sam się często zmagałem z tym problemem samodzielnie "stawiając" nasze strony internetowe.
Oto mój tok myślenia:
- Strona powinna oczywiście znajdować się na jakimś serwerze - serwer posiada adres IP i ma uruchomiony serwis http. W zadaniu adres IP serwera to 188.68.255.142.
- Kolejnym komponentem jest DNS. Na serwerze DNS powinny być skonfigurowane rekordy A przekierowujące "www.ccie.pl" oraz "ccie.pl" na adres IP serwera.
- Teraz czas by zabezpieczyć serwer. Generujemy za pomocą narzędzia Letsencrypt (lub kupujemy) certyfikat SSL. Podpięcie certyfikatu SSL do strony spowoduje, że wchodząc na "https://www.ccie.pl" lub "https://ccie.pl" będziemy mieli połączenie szyfrowane i wyświetli nam się kłódka.
- Warto też zaadresować sytuację, w której ktoś wejdzie na stronę używając prefiksu http:// - spowoduje to wyświetlenie strony niezabezpieczonej certyfikatem. Idzie to łatwo "naprawić" konfigurując HTTP Redirect - przekierowanie połączeń przychodzących na port 80 (http) na port 443 (https) - gdzie mamy certyfikat i szyfrowanie.
Po wykonaniu powyższych kroków nadal będziemy jednak mogli zaobserwować problem opisany w zadaniu.
Dlaczego?
Otóż generując certyfikat SSL powszechną praktyką jest generowanie go dla FQDN - czyli dla naszego adresu strony. Rzadko kiedy certyfikaty wydaje się dla adresów IP. Właśnie to będzie przyczyną wyświetlania błędu "połączenie nie jest bezpieczne".
Odpowiedź na pytanie
Jak zatem rozwiązać ten problem?
Ja widzę dwie możliwości. Można:
- Wydać certyfikat SSL dla adresu IP serwera - jest to jednak rzadko stosowane, lub,
- Skonfigurować w ustawieniach serwera (Apache lub NGINX) przekierowanie z adresu IP na adres domenowy serwera - uniemożliwiając tym samym "dobicie się" do serwera po jego adresie IP. To rozwiązanie też jest rzadko stosowane.
Skoro oba te rozwiązania są rzadko stosowane to jakie mamy alternatywy? W rzeczywistości powszechną (nie twierdzę, że poprawną) praktyką jest niezabezpieczanie połączeń kierowanych na adres IP serwera. Po prostu. ¯\(ツ)_/¯
Pytanie do Ciebie 📣
Jakie byłoby Twoje podejście do tego zadania?
Dostrzegasz inne możliwości rozwiązania tego problemu?
Podziel się swoim doświadczeniem i odpisz na tego maila.
Czytam i odpisuję na każdą wiadomość.
Warte uwagi 🤩
Kursy / Szkolenia
- Jeszcze dziś do 19:00 zdecydowanie warty Twojej uwagi będzie nasz kurs CCNA na https://szkolasieci.pl. To ostatnia szansa na dołączenie - wracamy dopiero na wiosnę!
Książki
"Wojownik Sieci" (ang. Network Warrior) wydaje się być klasyką wśród lektur na tematy sieciowe. Nadal jednak (ku mojemu zdziwieniu) okazuje się, że niewiele osób słyszało o tej książce - nie wspominając o jej przeczytaniu.
Jeżeli szukasz ciekawej lektury, która utrwali sporo podstawowych zagadnień sieciowych, to "Wojownik Sieci" z pewnością Ci się spodoba.
Na zakończenie
Święta już tuż tuż. U moich klientów dostrzegam spowolnienie w tempie pracy - świąteczna atmosfera zaczyna się udzielać. Pierwsze "change freeze'y" w wielu przypadkach zaczynają się już 17. grudnia.
A jak to wygląda w Twojej firmie?
Daj znać odpisując na tego maila 😎
Z sieciowym pozdrowieniem,
Damian Michalak