Tworzenie własnego urzędu certyfikacji dla intranetu

Muszę utworzyć własny ośrodek certyfikacji dla intranetu i niestety wydaje się, że nie ma dobrej odpowiedzi na ten temat w sekcji Bezpieczeństwo. SE.

W Internecie jest wiele zasobów na ten temat, ale wszystkie są inne, a niektóre używają nieaktualnych ustawień domyślnych (MD5 / SHA1 itp.), Co nie wydaje się godne zaufania. Istnieją również setki różnych odmian openssl.cnf, od 10-liniowego pliku do ogromnego, który był domyślnie dołączony do mojej dystrybucji.

Chciałbym kanoniczna odpowiedź na temat konfigurowania prostego urzędu certyfikacji do wydawania certyfikatów serwera i certyfikatów klienta.

Wygląda na to, że niektórzy ludzie wciąż nie rozumieją, że nie jestem jakąś dużą firmą, w której kompromis CA powoduje miliardy strat i nie można go łatwo złagodzić, więc pozwól mi wyjaśnić trochę lepiej, dlaczego potrzebuję CA:

  • Wiele serwerów połączonych za pomocą niezabezpieczonych łączy (Internet ) muszę się bezpiecznie komunikować.

  • Potrzebuję sposobu, aby zidentyfikować się na tych serwerach w celu wykonywania zadań administracyjnych, bez konieczności przechodzenia w tę iz powrotem do mojego menedżera haseł co 10 sekund.

  • żaden urząd certyfikacji niż mój nie powinien być w stanie podszyć się pod którykolwiek z serwerów, bez względu na to, jak mało prawdopodobne jest to ( ale możliwe ) to znaczy .

Tam. Moja własna PKI i certyfikat zainstalowany na każdej maszynie wydają się idealnie pasować do potrzeb. Jedno z używanych przeze mnie programów wymaga również użycia infrastruktury PKI, więc samo używanie certyfikatów z podpisem własnym nie wchodzi w grę.

Aby złamać PKI, ktoś musiałby zagrozić mojej maszynie roboczej, a jeśli to Po wykonaniu tej czynności atakujący może już wyrządzić sporo szkód, nawet nie dotykając PKI (ponieważ i tak logowałbym się przez SSH do serwera z tej maszyny). Akceptuję to ryzyko, a ten klucz PKI nie powoduje większego ryzyka niż to, które już istnieje.

Komentarze

  • echo "Abandon all hope, ye who enter here."
  • @KristoferA It ' s dla intranetu, ' jest bardziej niż rozsądne, aby utworzyć własny ośrodek certyfikacji dla sieci firmowej.
  • A tak przy okazji, co ' dzieje się z migracją do Superuser lub ServerFault? Czy nie jest ' czy użycie OpenSSL jest tutaj idealne?
  • ” … certyfikat z podpisem własnym jest certyfikat podpisany przez urząd nieznany większości systemów. ” Nie. Certyfikat z podpisem własnym to taki, w którym klucz publiczny, atrybuty zasad i atrybuty tożsamości zostały podpisane kluczem prywatnym odpowiadający kluczowi publicznemu związanemu z podpisem. Chociaż nie ma to nic wspólnego z tym, czy certyfikat pochodzi ze znanego źródła, prawdą jest – z definicji – że wszystkie certyfikaty główne są podpisane samodzielnie. Różnica polega na tym, że certyfikat główny jest włączony do podpisywania, ale nie do szyfrowania, co czyni go bezużytecznym jako certyfikat osobisty dla aplikacji lub serwera.
  • Co Andr é mówi, że oprogramowanie w szczególności nie zezwala na certyfikaty z podpisem własnym jako certyfikaty osobiste, a zarówno certyfikaty klienta, jak i serwera muszą mieć wspólny urząd certyfikacji. Chociaż są to nietypowe wymagania, są one całkowicie uzasadnione. Jednak żądanie dotyczy bardziej zasad, takich jak „, długość ścieżki certyfikatu głównego nie może być większa niż x ” i ” certyfikat osobisty musi zawierać flagę isCA=No i długość ścieżki równą zero. ” Niestety, zasady, na których opiera się większość zaufania w systemie, takie jak odwołanie, higiena przestrzeni nazw i zabezpieczenia rootów, nie są ' t adresowane w openssl.cnf.

Odpowiedź

Jeśli Twoja infrastruktura jest tiny , wiele szczegółów dotyczących prowadzenia urzędu certyfikacji (np. listy CRL itp.) można prawdopodobnie zignorować. Zamiast tego, jedyne, o co naprawdę musisz się martwić, to podpisywanie certyfikatów.

Istnieje wiele narzędzi, które zarządzają tym procesem za Ciebie. Napisałem o nich nawet wiele lat temu. Ale to, które polecam, jeśli chcesz czegoś naprawdę prostego to easy-rsa z projektu OpenVPN. Jest to bardzo cienka otoczka wokół narzędzia wiersza poleceń OpenSSL. Jeśli zamierzasz zarządzać DUŻĄ ilością certyfikatów i faktycznie zajmować się unieważnianiem i innymi rzeczami, będziesz potrzebować znacznie bardziej złożonego i kompletnego narzędzia. Podano więcej niż wystarczającą liczbę sugestii, więc zamiast tego po prostu trzymam się podstaw tego, co próbujesz osiągnąć.

Ale oto podstawowa procedura. Wyjaśnię to za pomocą OpenSSL , ale każdy system się nada.

Zacznij od utworzenia swojego „głównego” urzędu certyfikacji – będzie to certyfikat z podpisem własnym. Można to zrobić na kilka sposobów, to jest jeden. Zrobimy nasz 10-letni certyfikat z 2048-bitowym kluczem.Popraw liczby odpowiednio. Wspomniałeś, że martwisz się algorytmem haszowania, więc dodałem -sha256, aby upewnić się, że jest podpisany za pomocą czegoś akceptowalnego. Szyfruję klucz za pomocą AES-256, ale to jest opcjonalne . Zostaniesz poproszony o wypełnienie nazwy certyfikatu i tym podobnych; te szczegóły nie są szczególnie ważne dla głównego urzędu certyfikacji.

# First create the key (use 4096-bits if that"s what floats your boat) openssl genrsa -aes256 -out root.key 2048 # Then use that key to generate a self-signed cert openssl req -new -x509 -key root.key -out root.cer -days 3652 -sha256 

Jeśli zaszyfrowałeś klucz w pierwszym kroku, będziesz musiał podać hasło użyj go w drugim. Sprawdź wygenerowany certyfikat, aby upewnić się, że w sekcji „Podstawowe ograniczenia” widzisz „CA: TRUE”. To naprawdę jedyna ważna rzecz, o którą musisz się martwić:

openssl x509 -text < root.cer 

Świetnie. OK, teraz podpiszmy certyfikat. Będziemy potrzebować innego klucza i tym razem prośby. Ponownie zostaniesz zapytany o swoje imię i nazwisko oraz adres. To, jakie pola wypełnisz i co podasz, zależy od Ciebie i Twojego wniosku, ale najważniejszym polem jest „Nazwa zwyczajowa”. Tam podajesz swoją nazwę hosta lub nazwę logowania lub cokolwiek innego, co ten certyfikat ma poświadczyć.

# Create new key openssl genrsa -aes256 -out client1.key 2048 # Use that key to generate a request openssl req -new -key client1.key -out client1.req # Sign that request to generate a new cert openssl x509 -req -in client1.req -out client1.cer -CA root.cer -CAkey root.key -sha256 -CAcreateserial 

Zauważ, że tworzy to plik o nazwie root.srl do utrzymuj nasze numery seryjne prosto. Flaga -CAcreateserial mówi openssl, aby utworzył ten plik, więc podajesz go przy pierwszym podpisanym żądaniu, a potem już nigdy. I jeszcze raz możesz zobaczyć, gdzie aby dodać argument -sha256.

To podejście – robienie wszystkiego ręcznie – nie jest moim zdaniem najlepszym pomysłem. Jeśli wykonujesz dużą operację , wtedy prawdopodobnie będziesz potrzebować narzędzia, które będzie w stanie śledzić wszystkie Twoje certyfikaty.

Zamiast tego, moim celem było pokazanie, że pożądane wyniki – certyfikaty podpisane tak, jak chcesz – nie zależy od narzędzi, których używasz, ale raczej od opcji, które udostępniasz tym narzędziom. Większość narzędzi może generować szeroką gamę konfiguracji, zarówno mocnych, jak i słabych, i to do Ciebie należy podanie liczby, które chcesz m odpowiednie. Nieaktualne wartości domyślne są normalne dla kursu.

Komentarze

  • ' jest ważne, aby pamiętać, że kiedy Podpisujesz certyfikat klienta, jest to tylko część publiczna . Żaden klucz prywatny nie powinien być przesyłany ani generowany przez CA.
  • Czy mógłbyś rozszerzyć swoją odpowiedź na temat tworzenia pośredniego certyfikatu CA? Dzięki.
  • @Andr é Certyfikaty pośrednie to zwykłe certyfikaty z atrybutem basicConstraints = CA:TRUE ustawionym w rozszerzonych atrybutach. Nic magicznego, tylko kolejny certyfikat.
  • @tylerl Stary, rządzisz.
  • Ta odpowiedź jest FANTASTYCZNA i była bardzo pomocna, ale mam do dodania aktualizację z 2017 roku. Chrome i inne wymagają teraz rozszerzenia x509v3 subjectAlternativeName; w przeciwnym razie uznają certyfikat za nieważny, nawet jeśli certyfikat główny CA jest poprawnie zainstalowany w systemie. Przez jakiś czas walczyłem ze znalezieniem odpowiedniego rozwiązania. Ta strona była dla mnie bezcenna i rozwiązała ostatni element układanki: cmrg.fifthhorseman.net/wiki/SubjectAltName . IMO, dodanie sieci SAN podczas podpisywania, a nie podczas żądania, jest zarówno łatwiejsze, jak i bardziej podobne do tego, co faktycznie robią publiczne urzędy certyfikacji.

Odpowiedź

Jeśli naprawdę chcesz zostać urzędem certyfikacji, weź pod uwagę związane z tym konsekwencje dla bezpieczeństwa.

  1. Klucz prywatny używany do generowania głównego urzędu certyfikacji w intranecie powinien dosłownie być zamknięty w sejfie. Dostęp do wspomnianego sejfu powinien być fizycznie monitorowany.
  2. Korzystanie z głównego urzędu certyfikacji z podpisem własnym zmusza użytkowników do nie tylko zaufania, że wykonujesz należytą staranność w zakresie bezpiecznego zabezpieczenia kluczy, ale także do wstawienia początkowo niezaufanego roota mogą do swojego łańcucha certyfikatów.
  3. To również psuje funkcjonalność zszywania OSCP w odniesieniu do zewnętrznej weryfikacji łańcucha certyfikatów, co jest powodem, dla którego usługi zarządzania tożsamością istnieją w pierwszej kolejności.

Sporo osób argumentowałoby za zarządzaniem własnym CA, na przykład; jest przeznaczony dla firmowego intranetu, w którym część naszych komputerów stacjonarnych zawiera katalog główny, lub jest przeznaczony dla niewielkiej liczby użytkowników.

Chociaż niekoniecznie jest to złe i może przynosić pewne korzyści, zanegować łańcuch weryfikacji, dla którego zbudowano zarządzanie tożsamością opartą na certyfikatach.

Jeśli zdecydujesz się zaimplementować własny katalog główny, upewnij się, że postępujesz zgodnie z tymi samymi praktykami bezpieczeństwa, które są używane w przypadku każdego innego roota. Ostatnią rzeczą, jakiej byś sobie życzył, jest złamanie klucza prywatnego używanego w Twoim głównym CA i rozpoczęcie podpisywania certyfikatów dla kampanii phishingowych przeciwko Twoim klientom.

Dostępnych jest mnóstwo przewodników po najlepszych praktykach, NIST ( National Institute for Standard and Technology) to grupa współpracująca, pomagająca w opracowywaniu różnych standardów dotyczących zagadnień związanych z bezpieczeństwem komputerowym.

Zalecana lektura:
Audyt (PDF)
Odzyskiwanie po awarii (PDF)
Systemy klucza publicznego (PDF)
Instytut Sans dotyczący mniejsze wdrożenia PKI

OK Widzę, że zaktualizowałeś swoje pytanie, aby było bardziej szczegółowe.

Dwa dokumenty dotyczące konfigurowania pliku openssl.cnf ze szczegółami dotyczącymi urzędu certyfikacji:

https://www.openssl.org/docs/apps/ca.html

https://www.openssl.org/docs/apps/config.html

Zdaję sobie sprawę, że to może nie być odpowiedź, której chcesz, ale ponieważ środowisko i wymagania wszystkich są inne, zamierzasz musisz zdefiniować zakres implementacji CA dla dobrej przykładowej konfiguracji.

Komentarze

  • There ' nie ma powodu, dla którego Twój własny urząd certyfikacji nie może ' t używać OCSP. Nawet linia poleceń OpenSSL może to zrobić, a ' s o najniższym możliwym pasku.
  • linki openssl mają teraz 404

Odpowiedź

Tam nie da się tego zrobić po prostu. istnieje kilka narzędzi, które mogą pomóc w łatwym rozpoczęciu.

na przykład:

żaden z nich nie jest pełna PKI poza prawdopodobnie EJBCA, ale konfiguracja nie jest łatwa.

  • XCA to małe narzędzie frontendowe do uzyskiwania graficznego interfejsu do generowania, podpisywania i unieważniania certyfikatów.
  • Urząd certyfikacji EJBCA lub Enterprise Java Beans to aplikacja internetowa JBOSS / Jetty, która może wykonać pełną infrastrukturę PKI dla przedsiębiorstwa.
  • openssl to podstawowe narzędzie wiersza poleceń. może wykonać wszystkie bity offline urzędu certyfikacji, ale żadnej weryfikacji (po wyjęciu z pudełka). możesz za jego pomocą tworzyć własne weryfikatory OCSP, ale musisz sam stworzyć kod „online”.

Jeśli wszystko czego szukasz to poprawna konfiguracja openssl. XCA może pomóc w ich wygenerowaniu. (ma funkcję eksportu konfiguracji openssl

Komentarze

  • EJBCA ma teraz obraz maszyny wirtualnej, którego możesz użyć. W przeciwnym razie ” konfiguracja ” nie jest prosta. Jest to po prostu ogromny ant skrypt, który próbuje skonfigurować ( JBoss) serwer aplikacji, który może (iw moim przypadku będzie ) się zepsuł.
  • obraz maszyny wirtualnej służy do oceny, więc nie polecałbym go dla serwera produkcyjnego.
  • Mogę zajrzeć do XCA. EJBCA zdecydowanie nie jest ' żadną opcją – interfejs WWW dodaje niepotrzebnej powierzchni ataku i jest trudniejszy do skonfigurowania. Zdecydowanie wolę używać tylko openssl.
  • @Andr é w przypadku EJBCA, można go również używać z wiersza poleceń, więc wygrałeś ' nie trzeba ujawniać interfejsu internetowego. Ale jest to ' kwestia na poziomie przedsiębiorstwa i prawdopodobnie jest przesadą dla Twoich celów es (mówię to jako osoba, która zarabia na życie, pracując z tym).

Odpowiedz

Dla niektórych dobre tło, proszę zobaczyć moją prezentację Jak zbudować i prowadzić własne centrum zarządzania certyfikatami dla przeciętności . Istotą prezentacji jest to, że najbardziej potrzebna jest nie lista poleceń do uruchomienia, ale raczej dogłębne zrozumienie wszystkich różnych kontroli, które mają wpływ na prowadzenie komercyjnego urzędu certyfikacji, ich wzajemnych interakcji, dokładnego wpływu usunięcia wszelkich jeden z nich, skumulowany wpływ usunięcia kilku z nich oraz kontrole łagodzące niezbędne do zrekompensowania obniżonego poziomu bezpieczeństwa.

Dlatego nie ma „kanonicznej odpowiedzi na temat ustanowienia prostego CA”. Albo przechodzisz całą ścieżkę ISO, zaczynając od strony podpisującej klucz, zduplikowanych certyfikatów głównych z przerwami w dostępie i przechowywanych w magazynie, wielu pośredniczących sygnatariuszy, serwerów odwołań itp. itp., Lub musisz znaleźć kompromis w oparciu o unikalne koszty / korzyści i ryzyko profil firmy, który firma jest gotowa zaakceptować. Każdy, kto ma wystarczające umiejętności i doświadczenie, aby dokonać takiej oceny z definicji, nie potrzebuje ściągawki. Potrafią przeanalizować poprawną składnię komend w oparciu o dogłębne zrozumienie funkcji biznesowej, która ma zostać zrealizowana, oraz podstawowych zasad bezpieczeństwa używanych do implementacji tego wymagania.

Prezentacja zawiera historie z prawdziwych zaręczyn sklepów, które poszły tą drogą i potwornie się pomyliły. W niektórych przypadkach moja ocena wykazała, że absolutnie nic, co mogę zrobić z bezpieczeństwem oprogramowania pośredniego, nie jest w stanie przezwyciężyć nieodłącznych słabości wewnętrznego urzędu certyfikacji. Każdy w USA powinien zdać sobie sprawę, że prawdopodobnie kupuje usługi od przynajmniej jednego z dostawców, których dotyczy prezentacja. Są to banki, spółdzielcze kasy pożyczkowe, ubezpieczyciele zdrowotni, sprzedawcy detaliczni i nie tylko.

Ponieważ aby zalecenia były „poprawne”, osoba odpowiadająca musi przyjąć główne założenia dotyczące twoich akceptowalnych profili ryzyka, a od ciebie poczynić główne założenia dotyczące stopnia, w jakim twoje i ich wyobrażenia o ryzyku są dopasowane i w synchronizacji sama propozycja jest na pierwszy rzut oka ryzykowna. W większości takich przypadków ocena przydatności prowadzonych ćwiczeń ma więcej wspólnego z prezentacją niż z efektywnym poziomem bezpieczeństwa wynikającym z przestrzegania ich procedur. Jeśli jest dobrze zorganizowany i jasno wyartykułowany, ma to ZNACZNIE większe znaczenie niż to, czy jest skuteczny. Wybieramy kanoniczną ściągawkę, która wygląda najlepiej dla nas.

Z tych powodów nie sądzę, aby wiarygodny ekspert zapewnił „poprawne i aktualne openssl.cnf„, ale raczej może w najlepszym przypadku zapewnić proces oceny w celu pełniejszej oceny wymagań i akceptowalnego ryzyka. Ponieważ stawiasz firmę na wynik, żaden wiarygodny ekspert nie zrobiłby tego poza ochroną kontrakt. Wszelkie zalecenia, które otrzymujesz, będą prawie z definicji pochodzić od w wiarygodnego eksperta. Powodzenia.

Komentarze

  • Nawet w przypadku intranetu dla zasobów wewnętrznych? Możesz również wskazać, że prezentacja jest Twoja.
  • ” Nawet w przypadku intranet dla zasobów wewnętrznych? ” Szczególnie dla intranetu, ponieważ ' s gdzie najczęściej dochodzi do naruszeń danych. ” Możesz również wskazać że prezentacja należy do Ciebie. ” Wydawało mi się, że opisałem swoje doświadczenie w przeprowadzaniu ocen, ale uwaga. ' zaktualizowałem go.

Odpowiedź

Postępuj zgodnie z tymi instrukcje konfiguracji urzędu certyfikacji opartego na systemie Windows . Ponieważ wydajesz certyfikaty klienta, pamiętaj, że skróty SHA2 nie są obsługiwane w XP.

Prosta odpowiedź brzmi:

  1. Zainstaluj AD
  2. Zainstaluj urząd certyfikacji przedsiębiorstwa na kontrolerze domeny
  3. Edytuj szablon certyfikatu, aby wystawiać certyfikaty użytkownika końcowego (ustaw uprawnienia dla użytkowników do samodzielnej rejestracji lub przejdź do strony internetowej)
  4. Wdróż klucz publiczny certyfikatu głównego na wszystkich serwerach, które weryfikują użytkowników.
  5. Jeśli użytkownicy są w AD, użyj GPO, aby włączyć automatyczną rejestrację.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *