Pytanie:
Czy powinienem odrzucić żądanie CSR, gdy host wysłał mi e-mailem klucz prywatny do żądania certyfikatu SSL?
scipilot
2017-04-12 17:16:53 UTC
view on stackexchange narkive permalink

Poprosiłem właśnie o CSR od mojego dostawcy hostingu współdzielonego w celu wygenerowania certyfikatu, który odeślę do niego w celu zainstalowania. (Sam certyfikat ma być poprawnie wygenerowany przez organizację, dla której pracuję, która może dostarczyć certyfikaty do naszego oficjalnego użytku). Firma hostingowa niezwłocznie przesłała mi CSR, ale także klucz prywatny! Dali nawet CC kogoś innego i jest w Gmailu, więc Google prawdopodobnie już połknął go w celach reklamowych.

Moim skromnym zdaniem wydaje się to straszną rzeczą. Mam zamiar im odpisać odrzucając ten i prosząc o odnowienie CSR i tym razem zachowanie klucza prywatnego - prywatnego.

Zanim zrobię z siebie głupka, chciałbym to potwierdzić klucz prywatny do certyfikatu „SSL” (TLS) nigdy nie powinien opuszczać serwera?

Pracuję w branżach związanych z bezpieczeństwem od wielu lat i byłem programistą kryptograficznym, więc czuję Trochę znam ten temat - ale wiem, że z czasem wszystko się zmienia.

Przeczytałem pokrewne pytanie: Jakie problemy wynikają z udostępniania klucza prywatnego certyfikatu SSL?

Meta aktualizacja: zdałem sobie sprawę, że napisałem kiepski format pytania dla wymiany stosów - ponieważ teraz trudno jest zaakceptować konkretną odpowiedź. Przepraszam za to - wszystkie odpowiedzi dotyczyły różnych i równie interesujących aspektów. Początkowo zastanawiałem się, jak to sformułować w tym celu, ale zrobiłem to puste.

Aktualizacja: postępowałem zgodnie z tym z gospodarzem i „przeprosili za wszelkie niedogodności”, obiecali dotrzymać przyszłe klucze prywatne są „bezpieczne” i wydały mi nowy, inny CSR. Czy jest generowany z tego samego ujawnionego klucza prywatnego, którego obecnie nie jestem pewien. Zastanawiam się teraz również, ponieważ jest to host współdzielony, czy wysłali mi klucz do całego serwera, czy też każdy klient / domena / host wirtualny otrzyma parę kluczy.

To interesująca lekcja, jak siła kryptowalut na świecie może zostać unieważniona przez prosty błąd ludzki. Kevin Mitnik przytaknąłby.

Aktualizacja 2: W odpowiedzi na odpowiedź użytkownika @Beau użyłem następujących poleceń, aby sprawdzić, czy drugi CSR został wygenerowany z innego tajnego klucza prywatnego.

  openssl rsa -noout -modulus -in pk1. txt | openssl md5openssl req -noout -modulus -in csr1.txt | openssl md5openssl req -noout -modulus -in csr2.txt | openssl md5  

Pierwsze dwa hashe są identyczne, trzeci jest inny. To dobra wiadomość.

_ "i jest w Gmailu, więc prawdopodobnie Google już go połączył do celów reklamowych." _ Czy zdajesz sobie sprawę, że Google ma własny CA i może wstawić w zasadzie każdy certyfikat CA, który zechce, do Chrome?W tym scenariuszu Google jest prawdopodobnie jedną z najmniej zainteresowanych / interesujących stron.
Tak, nie martwię się o Google per se (powierzyłem im swoje życie!), Ale po prostu podkreślam dodatkowe podróże, którymi podróżują nasze osobiste treści, nawet po pozornym dotarciu do celu.
Czy klucz prywatny jest zaszyfrowany?
@DavidSchwartz Nie, tak nie wyglądało.
Przepraszam, że nie opublikowałem tego jako komentarza - nie mam wystarczającej liczby przedstawicieli.Ale możesz porównać swój nowy CSR z oryginalnym kluczem prywatnym za pomocą kilku poleceń openssl: https://www.sslshopper.com/certificate-key-matcher.html.Jeśli moduł dla każdego jest inny, to powinno być w porządku.Nie jestem jednak pewien, czy zaufałbym praktykom bezpieczeństwa dostawcy.W końcu bezpieczeństwo polega wyłącznie na zaufaniu.
To bardzo przydatne Beau - użyłem tych poleceń, aby udowodnić, że nowy CRS, który dostarczyli, został wygenerowany z innym kluczem prywatnym - co jest dobrą wiadomością, ponieważ nie muszę go też odrzucać.
Nie przepraszaj, myślę, że to moja wina, że piszę pytania opinii - to pytanie zamienia się w cenny artykuł na wiki :)
Swoją drogą to całkiem (nie) zabawne, że strona sslshopper.com ma pole „prześlij klucz prywatny”!I wielkie ostrzeżenie, żeby go nie używać.
W tym momencie przejście do firmy, która * faktycznie rozumie * naturę * prywatnego * klucza, może mieć więcej sensu, IMHO.Wydawca certyfikatów, który szczęśliwie wysyła klucze prywatne pocztą e-mail do kilku odbiorców, wydaje się * nie * wiedzieć, co robi, i okazał się nie być tak kompetentny.Czy używanie [certbot] (https://certbot.eff.org/) to problem?Właśnie tego używam na moim serwerze.
@BaileyS Google firma może nie być zainteresowana, ale Dave pracownik Google z dostępem do serwera pocztowego może być.Zdarzały się przypadki nadużywania dostępu do kont Gmail innych osób przez pracowników Google
@Pharap wartość prywatnych informacji danej osoby jest wysoce przeceniona.Naprawdę, nikogo nie obchodzą sekrety, które możesz mieć tak drogie, miażdżenie Facebooka, dzienniki czatów i prawdopodobne nagości przechowywane w kopii zapasowej WhatsApp.Trudno przyznać, że nie jesteśmy aż tacy interesujący, a większość z nas jest zwyczajnie nudna.Prawdziwa wartość pochodzi z ogromnych ilości zagregowanych danych, w których Twoja indywidualność rozpływa się w nicości w porównaniu ze zbiorem danych.O ile, oczywiście, nie jesteś gorącą nastolatką Putina lub prezesem F500, nasze prywatne dane nie są warte żadnego wysiłku.
@hlecuanda Cóż.[ten facet] (http://gawker.com/5637234/gcreep-google-engineer-stalked-teens-spied-on-chats) z pewnością był.Miło mi słyszeć, że moja komunikacja za pośrednictwem Gmaila z moimi hakerami z pięciokąta jest bezpieczna.Na pewno powiem Betty, żeby była ostrożna, bo ktoś mógł się zorientować, z którą głową państwa zaaranżowała porozumienie w sprawie pokoju hotelowego.
Sześć odpowiedzi:
dr_
2017-04-12 17:52:09 UTC
view on stackexchange narkive permalink

Tak, zdecydowanie należy odrzucić CSR. Dodatkowo powinieneś zmienić swojego dostawcę usług hostingowych, ponieważ wygląda na to, że nie wiedzą, co robią.

Już wystarczająco źle, że wysłali Ci klucz prywatny e-mailem, tj. Przez niezabezpieczone medium . Jednak przesłali go również komuś innemu, co stanowi całkowite naruszenie poufności.

Ponadto zastanawiam się, dlaczego wysłali Ci klucz prywatny - powinien on być zainstalowany na serwerze, co mogą zrobić samodzielnie.

Podali drugi kontakt na koncie (nie techniczny).I tak, zastanawiałem się też, dlaczego, to było naprawdę moje pytanie.Nadal nie ma powodu - po prostu upewniam się, że nie przegapiłem tutaj notatki.
Ok, więc to nie tak, że wysłali klucz prywatny do kogoś nieznanego ci.Jednak główny punkt jest aktualny.
@dr01 Pewnie, że tak.Wszyscy administratorzy serwerów pocztowych, administratorzy routerów i administratorzy zapory ogniowej, którzy byli po drodze i chcieli ją przeczytać.
@DRF Chodziło mi o to, że * dobrowolnie * ujawnił klucz prywatny osobom trzecim.
Zastanawiam się, czy klucz prywatny jest używany dla całego serwera współdzielonego, w którym to przypadku byłbyś w stanie podszyć się pod nie tylko swoją domenę, ale każdego innego korzystającego z tego samego serwera.
@dr01 Myślę, że jeśli wysyłasz informacje w e-mailu, chyba że są one zaszyfrowane, dobrowolnie ujawniasz je każdemu komputerowi, od którego odbija się, dopóki nie dotrze do miejsca przeznaczenia.
+1 za polecenie OP, aby zmienił dostawcę, który wykazał się ignorancją w swojej dziedzinie.
@AaronHall Jest to dobrowolne tylko wtedy, gdy wiesz, jak działa poczta e-mail, w przeciwnym razie jest to błoga ignorancja.Myślę, że ustaliliśmy, że dostawca hostingu jest prowadzony przez niekompetentnych pracowników.
vakus
2017-04-12 17:40:50 UTC
view on stackexchange narkive permalink

Gdybym był na twoim miejscu, odmówiłbym akceptacji tego certyfikatu SSL. Powodem jest to, że gdyby ktoś włamał się do któregokolwiek z e-maili, które otrzymały klucz prywatny, byłby w stanie go pobrać, a następnie podszyć się pod serwer w różnych atakach na klientów, np. man in the middle lub tym podobne, również w przypadku, gdy jeden z otrzymujących adresów e-mail został wpisany niepoprawnie, ktoś może już mieć klucz prywatny. Prawdopodobnie istnieje również wiele innych scenariuszy, w których ten klucz prywatny może zostać pobrany i wykorzystany przez atakującego.

Ważne jest również powiadomienie firmy o nieudostępnianiu klucza prywatnego, aby upewnić się, że firma nie wysłał klucz prywatny gdziekolwiek indziej - klucz prywatny został wysłany do Ciebie i kilka innych CC w tym e-mailu, ale nie możesz wiedzieć, czy firma nie wysłała oddzielnego e-maila z kluczem prywatnym gdzie indziej.

Jest powód, dla którego klucz prywatny nazywany jest kluczem prywatnym

Pamiętaj, że jest to głównie moja osobista opinia i nie jestem ekspertem w zakresie SSL.

Tak, dobra uwaga, jeśli chodzi o ich edukację.
Czy w tym momencie przejście do firmy, która faktycznie rozumie naturę klucza prywatnego, nie miałoby większego sensu?Wydawca certyfikatów, który szczęśliwie wysyła klucze prywatne pocztą e-mail do kilku odbiorców, wydaje się * nie * wiedzieć, co robi i okazał się nie być tak kompetentny, IMHO.
@ray dobrze, jeśli zmienisz firmę, będziesz bezpieczniejszy, ale jeśli zamiast tego będziesz ich edukować, wszyscy ich klienci będą bezpieczni.Jeśli ich edukacja nie pomoże, to tak, rozsądnie byłoby zmienić firmę, ale w tym momencie wydaje się to oczywiste
@vakus Jeśli chcesz zainwestować w edukację kogoś, kto już powinien wiedzieć lepiej, to zależy od Ciebie.Pamiętaj tylko, że słaba praktyka bezpieczeństwa widoczna dla Ciebie, będąc poza firmą, wskazuje na głębsze problemy, których możesz nigdy nie odkryć (np. Skąd wiesz, że nie udało im się udostępnić tego klucza na inne adresy lub gorzej?), A zatem nie jest w stanieaby ich uczyć.Musisz zdecydować, na jakie ryzyko zamierzasz narazić * swoich * klientów w celu ich „edukacji”.Edukacja ich nie oznacza, że musisz pozostać ich klientem.Odejście może zachęcić ich do tego, by się naprawili
Lie Ryan
2017-04-12 20:25:21 UTC
view on stackexchange narkive permalink

Tak, zdecydowanie powinieneś odrzucić CSR.

To zależy od tego, czy powinieneś ponownie rozważyć dostawcę usług hostingowych.

Skontaktowali się nawet z kimś innym,

Czy są jakieś powody, dla których firma hostingowa powinna znać wewnętrzną strukturę Twojej firmy? Czy osoba, która to robi, jest wyznaczonym opiekunem klienta, który został specjalnie przypisany do Twojej firmy i jest odpowiedzialny za ustalenie, kto jest kim w Twojej firmie? Czy Twoja firma dostarczyła opiekunowi konta wystarczające informacje na temat struktury Twojej firmy i kto jest do czego upoważniony? Jeśli nie, to częściowo może to być wina Twojej (firmy), która nie wyjaśniła im, w jaki sposób powinni wysłać Ci klucz.

W większości kont hostingowych, jeśli nie masz wyznaczonego konta menedżerowi, który jest zaznajomiony z Twoją branżą, powinieneś był bardzo wyraźnie powiedzieć jego pomocy technicznej, jak wysłać klucze do Ciebie, kto powinien je otrzymać i czy chcesz otrzymać klucz w pierwszej kolejności. Nie zakładaj, że personel pomocy technicznej zna sytuację Twojej firmy i nigdy nie zakładaj, że personel pomocy technicznej, który nie jest wyznaczonym menedżerem konta, zapamięta, kim jesteś z poprzedniej interakcji.

i jest w Gmailu

Zdajesz sobie sprawę, że wysłanie CSR przez e-mail również nie jest zbyt bezpieczne, prawda? Jest całkiem możliwe, że ktoś (insider pracujący w Gmailu lub APT) przechwyci wiadomość e-mail zawierającą CSR, zastąpi CSR, który host wysyła swoim własnym CSR, i sam podpisze CSR firmy hostingowej do firmy hostingowej. Pozwoliłoby im to później wykorzystać sfałszowane certyfikaty do MITM między Tobą a Twoimi użytkownikami i firmą hostingową.

CSR musi być dostarczony przez uwierzytelniony kanał (np. przesyła certyfikat do witryny HTTPS, którą kontrolujesz lub powinien podpisać CSR kluczem GPG, który publikuje na swojej stronie) lub przynajmniej powinieneś zrobić odcisk palca weryfikacja, a zarówno Ty, jak i Twój host musicie mieć sposób na zidentyfikowanie i uwierzytelnienie drugiej strony. Utworzenie uwierzytelnionego kanału może być dość skomplikowanym procesem i nie jest czymś, co będzie dostępne w tańszych dostawcach hostingu lub takich, które nie specjalizują się w hostingu biznesowym o wysokim poziomie bezpieczeństwa.

Jeśli tego nie zrobisz Nie określaj, w jaki sposób Twoja firma wymaga dostarczania CSR, a zwłaszcza jeśli nie obsługuje Cię menedżer konta, który powinien wiedzieć, jaki rodzaj działalności prowadzisz, wtedy większość firm hostingowych rozsądnie założyłaby, że jesteś firmą o minimalnym poziomie bezpieczeństwa. Większość osób pracujących w firmach zajmujących się minimalnymi zabezpieczeniami uznałaby, że posiadanie kopii klucza prywatnego ma wyższą wartość niż bezpieczeństwo wynikające z braku kontroli klucza, nie jest nierozsądne, aby zakładali to od Ciebie.

`Jest całkiem możliwe, że ktoś ... przechwyci wiadomość e-mail zawierającą CSR` - Czy masz link lub coś, co zawiera więcej szczegółów na ten temat?Staram się śledzić, jak to by działało.
@Zoredache To bardzo proste.Pracujesz w Google.Uruchamiasz skrypt, aby wyszukać niedostarczoną wiadomość e-mail w bazie danych Gmaila, która została wysłana do użytkowników w ciągu ostatnich 5 minut i zawiera coś, co wygląda na ładunki klucza prywatnego.Tymczasowo przenosisz tę wiadomość e-mail do strefy przeciwności, aby nie została dostarczona, a następnie tworzysz alternatywny ładunek.Następnie umieszczasz zmodyfikowaną wiadomość e-mail ze złośliwym ładunkiem z powrotem w bazie danych, gdzie użytkownik zobaczy ją jako kolejny, oczekiwany, dobry e-mail.
HTTPS nic nie pomoże, chyba że ma uwierzytelnienie klienta, ale równie dobrze możesz po prostu podpisać CSR certyfikatem klienta i mieć mniej pracy.Jedynym bezpiecznym sposobem dostarczenia CSR jest użycie uwierzytelniania poza pasmem.W zależności od tego, jak bezpieczne jest to, co chcesz, może to być tak proste, jak rozmowa telefoniczna i odczytanie odcisku palca lub tak irytujące, jak konieczność osobistego stawienia się.
@ErikE Oczywiście, jeśli klucz prywatny jest wysłany, jest problem, ale odpowiedź LieRyan mówi, że sam CSR w e-mailu może być nadużywany.Nie podążam za tym, jak można wykorzystać MITM mając tylko CSR.Chyba że myślisz, że atakujący może przechwycić CSR i jest również skonfigurowany do MITM, aby uzyskać dostęp do serwera, dla którego certyfikat jest faktycznie wystawiany.
@Zoredache Samo przesłanie CSR (bez klucza prywatnego) nie stwarza żadnego zagrożenia bezpieczeństwa.Żądający wygenerował parę kluczy prywatny-publiczny, który chce powiązać z jednostką, która ma być chroniona (np. Użyć z witryną https dla www.example.com) i uprzejmie prosi zaufanego sygnatariusza o podpisanie, a tym samym potwierdzenie, żeto połączenie między kluczem publicznym a powiązaną jednostką istnieje.To, co musi odbywać się w bezpieczny sposób poza pasmem, to raczej proces weryfikacji, czy CSR został wydany przez kogoś, kto ma wiarygodną kontrolę nad podmiotem, który ma być chroniony.
Tak, zdaję sobie sprawę, że zwykła poczta e-mail jest również niedopuszczalnie niepewna, po prostu wydaje się, że w dzisiejszych czasach poczta elektroniczna jest mniej ceniona przez osoby fizyczne, a akceptacja dostępu stron trzecich jest bardziej normalna.Kiedyś tak naprawdę tylko administratorzy / administratorzy poczty mieli dostęp do treści poczty, gdy byli w kolejce, w zwykłej tradycyjnej wiadomości e-mail.Teraz jest o wiele bardziej złożony, z większą liczbą powierzchni ataku i niższym poziomem personelu z potencjalnym dostępem (wydaje mi się).Przez Gmaila miałem na myśli również pocztę internetową, więc np.Ad Block Pro i wszystkie inne wtyczki do przeglądarek prawdopodobnie „czytają” moje e-maile.
To bardzo dobra i oryginalna uwaga, że nie sprecyzowałem, jak ją dostarczyć.Prawdopodobnie masz rację, ustawiłem poprzeczkę domyślnie nisko.Ale poprosiłem ich tylko o CSR, którym moim zdaniem można się podzielić, więc nie podniosło to mojego normalnego poziomu świadomości, np.w przeszłości prosiłem hostów o zapisywanie danych logowania do pliku w środowisku hostowanym, do którego mam dostęp (przez SCP).
Powinienem był wspomnieć, że osoba, do której dodano kopię zapasową, to „Właściciel konta”, a ja jestem „Kontaktem technicznym”, więc wydaje się, że zawsze do nich dzwonią.Nie wyszkoliłem tej osoby, ponieważ nie spodziewałem się problemu.
@Zoredache: tak, miałem na myśli kogoś, kto również może skonfigurować MITM, na przykład administratora dowolnego systemu w ścieżce sieciowej centrum danych / upstream hosta lub kogoś, kto prowadzi [szeroko używany publiczny DNS] (https: // programiści.google.com/speed/public-dns/).Ktoś, kto może przechwycić Twoje wiadomości, może przynajmniej zmodyfikować Twój e-mail, aby zawierał dwa CSR, prawdziwy i sfałszowany, i opowiedzieć wiarygodną historię z okładki, taką jak posiadanie nadmiarowego modułu równoważenia obciążenia, w którym instaluje oddzielny certyfikat, a HSM tego nie robi.obsługuje eksport klucza prywatnego.
„Konfiguracja uwierzytelnionego kanału może być dość skomplikowanym procesem” - czy liczysz keybase.io jako kanał uwierzytelniony?
Peter Green
2017-04-13 02:59:57 UTC
view on stackexchange narkive permalink

Zanim zrobię z siebie głupka, chciałbym potwierdzić, że klucz prywatny certyfikatu „SSL” (TLS) nigdy nie powinien opuszczać serwera?

To zależy, mogą istnieć dobre powody, aby opuścić serwer. Na przykład możesz chcieć użyć tego samego certyfikatu na serwerach serwerowych lub możesz potrzebować klucza zapasowego do przypinania klucza.

Ale absolutnie powinno być traktowane jako cenny sekret, tylko przechowywane na zaufanych komputerach i jeśli zachodzi potrzeba przemieszczania się między systemami, należy to zrobić w odpowiednio zabezpieczony sposób.

Radzę natychmiast odejść od tych klaunów.

Słuszna uwaga, sam to robiłem w przeszłości.Robiąc to, poczułem się odpowiednio zdenerwowany i użyłem SSH do przesłania go bezpośrednio do drugiego hosta.
trognanders
2017-04-13 03:33:08 UTC
view on stackexchange narkive permalink

Prawdopodobnie chcieli, abyś miał całą parę klucz / certyfikat na wypadek, gdybyś chciał jej użyć gdzie indziej.

Posiadanie klucza prywatnego w pobliżu jest uzasadnionym problemem bezpieczeństwa, szczególnie jeśli nie zamierzasz go używać. Wyjaśnij, że ten certyfikat jest przeznaczony tylko dla dostawcy usług hostingowych i poproś go o ponowne wydanie CSR i wysłanie go bez klucza prywatnego. Sprawdź, czy odcisk palca CSR się zmienia.

Wygląda na to, że traktują certyfikat jako sposób na wyświetlenie zielonej kłódki, a nie jako urządzenie zabezpieczające, co prawdopodobnie jest znakiem ostrzegawczym. Rozważ inny hosting, jeśli jest to możliwe i / lub jeśli Twoja witryna obsługuje bardzo poufne informacje.

Marquis of Lorne
2017-04-13 05:47:10 UTC
view on stackexchange narkive permalink

Są całkowicie niekompetentni pod względem bezpieczeństwa. Klucz prywatny z definicji jest, err, prywatny. Służy do legalnej identyfikacji właściciela. Umożliwili fałszerstwo i podszywanie się.

Powinieneś wysłać im CSR, po wygenerowaniu go samodzielnie z twoja para kluczy prywatny / publiczny i oni powinni wysłać podpisany certyfikat i jego łańcuch uwierzytelniania. Nic więcej.

Jeśli wysyłają Ci klucze prywatne i CSR, cały ich model jest zepsuty.

Zmień dostawców i odzyskaj swoje pieniądze. Na najmniej. Narażają Twoje bezpieczeństwo, więc może zostać wniesione powództwo o utratę i odszkodowanie. Przynajmniej możesz im zagrozić, aby ułatwić proces zwrotu pieniędzy.

Jestem prawie pewien, że nie _ legalnie_ identyfikuje właściciela, tylko technologicznie.
Myślę, że źle zrozumiałeś rolę dostawcy tutaj (chyba że ja): nie wystawiają certyfikatu, instalują go na serwerze, do którego OP ma tylko ograniczony dostęp.OP nie może wygenerować pary kluczy, ponieważ nie ma dostępu do zainstalowania klucza prywatnego w konfiguracji serwera WWW.Gdyby to zrobili, * oni * musieliby przesłać klucz prywatny * do hosta *.Host generujący parę kluczy i wysyłający CSR wydaje się być absolutnie właściwym procesem, ale nie trafił w sedno, udostępniając klucz prywatny.
@QPaysTaxes Podpis cyfrowy z kluczem prywatnym jest prawnie wykonalny jako całkowicie równoważny z osobistym podpisem na umowie lub czeku.
@IMSoP Jeśli więcej niż jedna osoba ma klucz prywatny, nie jest on prywatny.Jeśli tak interpretuje się rolę dostawcy, jest to radykalnie niepewne.Rozsyłanie go w ogóle całkowicie narusza PKI.
@EJP Huh, nie miałem pojęcia.To fajnie!Czy z ciekawości możesz przytoczyć konkretne prawo / orzeczenie, które to spowodowało?Czy jest to globalne, powszechne lub specyficzne dla Stanów Zjednoczonych?
@QPaysTaxes * Celem * podpisów cyfrowych jest zgodność z prawem.Jest to dobrze ugruntowane prawo w USA, Australii, Wielkiej Brytanii… Nie jestem prawnikiem i nie mogę przedstawić żądanych referencji.
@EJP Tak, rozumiem.Ale przegapiłeś punkt w pierwotnym pytaniu, że jedyną osobą, która powinna posiadać ten konkretny klucz prywatny, jest usługodawca hostingowy.Wszyscy zgadzamy się, że zrobili źle, udostępniając go, ale twoja sugestia, że OP powinien wygenerować własną parę kluczy, nie ma sensu, ponieważ klucz prywatny musi znaleźć się w konfiguracji serwera, do której ma dostęp tylko firma hostingowa.


To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...