WP Migrate DB Pro (Polski)
Lokalne konfigurowanie HTTPS może być trudne. Nawet jeśli uda Ci się zmusić samopodpisane certyfikaty do przesłania, nadal będziesz mieć błędy prywatności przeglądarki. W tym artykule omówimy tworzenie własnego urzędu certyfikacji dla lokalnych serwerów, aby można było bez problemu uruchamiać witryny HTTPS lokalnie.
Dlaczego HTTPS lokalnie?
Dlaczego nie tylko używać lokalnie zwykłego protokołu HTTP? Ponieważ jeśli Twoja witryna produkcyjna obsługuje wyłącznie protokół HTTPS i tworzysz lokalnie przy użyciu zwykłego protokołu HTTP, Twoje środowiska deweloperskie i produkcyjne nie są tak podobne, jak mogłyby być. Na przykład moje środowisko programistyczne dla tej witryny (deliciousbrains.com) działa jako serwer Ubuntu na maszynie wirtualnej VMware (VM) na jego Macu. Witryna produkcyjna to serwer Ubuntu działający na Linode z prawie identyczną konfiguracją.
Zdecydowanie chcesz, aby środowisko deweloperskie jak najdokładniej odzwierciedlało produkcję.
Jeśli tak się nie stanie, zapraszaj więcej problemów pojawia się w produkcji, ale nie pojawia się w wersji dev. Uruchamianie protokołu HTTP, gdy Twoja witryna produkcyjna obsługuje wyłącznie HTTPS, jest zdecydowanie niepotrzebnym ryzykiem.
Jednak próba uzyskania certyfikatu SSL działającego z lokalnym serwerem jest do dupy, jeśli nie używasz narzędzia, które go obsługuje dla Ciebie lubisz Valet.
Jeśli kiedykolwiek próbowałeś lokalnie uruchomić witrynę HTTPS, prawdopodobnie widziałeś coś takiego w Chrome:
Sposób obejścia tego problemu polegał na tworzeniu certyfikatu z podpisem własnym i używaniu go. MAMP Pro robi to dla Ciebie i był moim celem przez lata. Niestety nie jest to już możliwe. Nowoczesne podejście polega na zostaniu własnym urzędem certyfikacji (CA)!
Jak to działa
Aby zażądać certyfikatu SSL od urzędu certyfikacji, takiego jak Verisign lub GoDaddy, wysyłasz mu podpisanie certyfikatu Żądanie (CSR), a oni w zamian dają ci certyfikat, który podpisali przy użyciu swojego certyfikatu głównego i klucza prywatnego. Wszystkie przeglądarki mają kopię (lub mają do niej dostęp z systemu operacyjnego) głównego certyfikatu Verisign, dzięki czemu przeglądarka może zweryfikować, czy Twój certyfikat został podpisany przez zaufany urząd certyfikacji.
Właśnie dlatego, gdy generujesz własny certyfikat podpisany certyfikat, którego przeglądarka nie ufa. Jest podpisany samodzielnie. Nie został podpisany przez urząd certyfikacji. Ale możemy wygenerować własny certyfikat główny i klucz prywatny. Następnie dodajemy certyfikat główny do wszystkich posiadanych przez nas urządzeń tylko raz, a wszystkie generowane i podpisywane przez nas certyfikaty będą z natury zaufane.
Zostanie (małym) urzędem certyfikacji
To trochę śmieszne, jak łatwo jest generować pliki potrzebne do zostania urzędem certyfikacji. Potrzeba tylko dwóch poleceń. Najpierw generujemy nasz klucz prywatny:
Zostaniesz poproszony o podanie hasła, którego nie polecam pomijać i zachować bezpieczeństwo. Fraza hasła uniemożliwi każdemu, kto uzyska Twój klucz prywatny, wygenerowanie własnego certyfikatu głównego. Wynik powinien wyglądać następująco:
Następnie generujemy certyfikat główny:
Zostaniesz poproszony o podanie hasła do klucza prywatnego (którą właśnie wybrałeś) i kilka pytań. Odpowiedzi na te pytania nie są takie ważne. Pojawiają się, gdy patrzysz na certyfikat, czego prawie nigdy nie zrobisz. Sugeruję, aby nazwa pospolita była czymś, co będzie rozpoznawać jako certyfikat główny na liście innych certyfikatów. To naprawdę jedyna rzecz, która ma znaczenie.
Powinieneś teraz mieć dwa pliki: myCA.key (Twój klucz prywatny) i myCA.pem (Twój certyfikat główny ).
🎉 Gratulacje, jesteś teraz CA. Coś w rodzaju.
Aby zostać prawdziwym CA, musisz mieć swój główny certyfikat na wszystkich urządzeniach na świecie. Zacznijmy od tych, które posiadasz.
Instalowanie certyfikatu głównego
Musimy dodać certyfikat główny do wszystkich laptopów, komputerów stacjonarnych, tabletów i telefonów, które będą miały dostęp do Twoich witryn HTTPS . Może to być trochę uciążliwe, ale dobrą wiadomością jest to, że musimy to zrobić tylko raz. Gdy nasz certyfikat główny znajdzie się na każdym urządzeniu, będzie działał, dopóki nie wygaśnie.
Dodawanie certyfikatu głównego do pęku kluczy systemu macOS
Przez CLI
Za pomocą interfejsu użytkownika
- Otwórz aplikację pęku kluczy w systemie macOS
- Przejdź do pliku > Importuj elementy…
- Wybierz plik klucza prywatnego (np. MyCA.pem)
- Wyszukaj cokolwiek, na co odpowiedziałeś, jako nazwę zwykłą powyżej
- Kliknij dwukrotnie certyfikat główny na liście
- Rozwiń sekcję Zaufanie
- Zmień pole wyboru Podczas używania tego certyfikatu: na „Zawsze Trust ”
- Zamknij okno certyfikatu
- Poprosi Cię o wpisanie hasła (lub zeskanowanie palca), zrób to
- 🎉 Świętuj!
Dodawanie certyfikatu głównego do systemu iOS
Jeśli chcesz dodać certyfikat główny do urządzeń z systemem iOS, możesz to dość łatwo zrobić, wykonując następujące kroki:
- Wyślij certyfikat główny e-mailem do siebie, aby uzyskać do niego dostęp na urządzeniu z systemem iOS
- Kliknij załącznik w wiadomości e-mail na urządzeniu z systemem iOS
- Przejdź do aplikacji ustawień i kliknij „Profil pobrany” u góry
- Kliknij zainstaluj w prawym górnym rogu
- Po zainstalowaniu kliknij zamknij i wróć do głównej strony ustawień
- Przejdź do „General” > „About”
- Przewiń w dół i kliknij „Certificate Trust Settings”
- Włącz certyfikat główny w sekcji „WŁĄCZ PEŁNE ZAUFANIE DLA CERTYFIKATÓW ROOT”
Tworzenie certyfikatów podpisanych przez urząd certyfikacji dla Witryny deweloperskie
Teraz, gdy jesteśmy CA na wszystkich naszych urządzeniach, możemy podpisywać certyfikaty dla wszystkich nowych witryn deweloperskich, które wymagają protokołu HTTPS. Najpierw tworzymy klucz prywatny:
Następnie tworzymy CSR:
Otrzymasz te same pytania, co powyżej i znowu Twoje odpowiedzi nie mają znaczenia. W rzeczywistości mają one jeszcze mniejsze znaczenie, ponieważ nie będziesz patrzeć na ten certyfikat na liście obok innych.
Następnie utworzymy certyfikat używając naszego CSR, klucza prywatnego CA, certyfikatu CA i pliku konfiguracyjnego, ale najpierw musimy utworzyć ten plik konfiguracyjny.
Plik konfiguracyjny jest potrzebny do zdefiniowania rozszerzenia Subject Alternative Name (SAN) który jest zdefiniowany w tej sekcji (tj. rozszerzenie) certyfikatu:
Plik konfiguracyjny (dev.deliciousbrains.com. ext) zawierał:
Uruchomimy polecenie openssl x509
, ponieważ z tego, co rozumiem, Do podpisania przy użyciu certyfikatu głównego i klucza prywatnego potrzebne jest polecenie x509. Znalazłem ten przykładowy plik konfiguracyjny na Stack Overflow i wygląda na to, że działa.
Teraz uruchamiamy polecenie, aby utworzyć certyfikat:
Mogę teraz skonfigurować mój serwer sieciowy za pomocą klucza prywatnego i certyfikat. Jeśli korzystasz z serwera Linux, możesz skorzystać z instrukcji z naszej serii Instalowanie WordPress na Ubuntu 20.04. Jeśli używasz MAMP, możesz wybrać certyfikat i pliki kluczy za pomocą interfejsu użytkownika:
Niestety MAMP (testowany z wersją 5.7) nie tworzy certyfikatów SSL z CA, więc na razie będziesz musiał użyć metody ręcznej.
W przypadku innych witryn deweloperów możemy powtórzyć tę ostatnią część tworzenia certyfikatu, nie musimy tworzyć nowego CA dla każdej witryny.
Skrypt powłoki
Aby uczynić rzeczy jeszcze szybszymi, oto przydatny skrypt powłoki, który możesz zmodyfikować do własnych celów:
Wniosek
Więc masz to, jak stać się własnym lokalnym certyfikatem uprawnienia do podpisywania lokalnych certyfikatów SSL i używania protokołu HTTPS w witrynach lokalnych. Mamy nadzieję, że wyeliminuje to przerażającą wiadomość „Twoje połączenie nie jest prywatne” w Chrome.