Czy podczas tworzenia certyfikatów z podpisem własnym należy zainstalować plik CA.crt na komputerze klienckim?

Sam łańcuch zaufania można wyjaśnić za pomocą struktury certyfikatu.

Jeśli zaczniemy od certyfikatu serwera (tj. certyfikat, którego zwykle używasz dla apache):

• Twój certyfikat serwera jest generowany przez urząd certyfikacji na podstawie dostarczonego przez Ciebie CSR. Ten CSR zawiera Twój klucz publiczny i inne informacje, których wykorzystanie może być zainteresowane lub nie.
• urząd certyfikacji otrzymuje Twój CSR i (ogólnie) tworzy podpisany certyfikat przy użyciu pośredniego urzędu certyfikacji. Twój certyfikat będzie miał dwa klucze publiczne: jeden dla podmiotu (który jest kluczem publicznym wyodrębnionym z Twojego CSR) i jeden dla strony wystawiającej, czyli pośredniego certyfikatu urzędu certyfikacji.
• CA ” Certyfikat pośredni jest sam w sobie certyfikatem podpisanym (z pewnymi specjalnymi opcjami), w którym klucz podmiotu będzie kluczem publicznym pośredniego urzędu certyfikacji (który jest tym samym kluczem publicznym, który znajduje się w kluczu publicznym wystawcy certyfikatu serwera). klucz podpisujący (lub wystawiający) będzie certyfikatem głównym urzędu certyfikacji (alternatywnie będzie to inny pośredni certyfikat).
• certyfikat główny urzędu certyfikacji jest (ogólnie) certyfikatem z podpisem własnym. W praktyce oznacza to, że klucze wystawcy i podmiotu są tym samym kluczem publicznym.

Możesz to zobaczyć, sprawdzając certyfikaty w środowisku naturalnym, np .:

$ openssl s_client -connect google.com:443 < /dev/null CONNECTED(00000003) depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority 

Łańcuch zaufania, jaki ten buduje, można podsumować następująco (Zaczynam od „ bottom „- certyfikat Equifax):

• główny urząd certyfikacji (Equifax) deleguje codzienne czynności do pośredniego urzędu certyfikacji (GeoTrust) i podpisuje certyfikat potwierdzający ten fakt (tj. ustawienie urzędu certyfikacji: TRUE, KeyUsage: keyCertSign). Innymi słowy, główny urząd certyfikacji „ufa” pośrednikowi w wydawaniu certyfikatów w jego imieniu (miejmy nadzieję, że po wykonaniu szeregu obowiązkowych kroków weryfikacji).
• w tym łańcuchu pośredni (Geotrust) przekazał ponadto delegację do urzędu certyfikacji Google (CN = Google Internet Authority G2).
• delegat (aka pośredni CA Google) następnie podpisuje CSR, który w rzeczywistości jest dokumentem stwierdzającym zbiór nazw (t CN i ewentualnie Alternatywne nazwy podmiotu), para kluczy prywatny / publiczny jest ważna / zaufana (zaufanie wynika z faktu, że potwierdzili oni roszczenie do wypowiadania się w imieniu danej nazwy – w tym przypadku urząd certyfikacji Google wydał certyfikat dla * .google.com).

Zwróć uwagę, że (główne) urzędy certyfikacji są na ogół z podpisem własnym – urząd certyfikacji jest ogólnie zaufany, ponieważ przestrzega zestawu procesów i procedur, które są uważane za zapewniające, że nie wydaje certyfikatów ludziom kto nie powinien ich mieć. Dlatego nie mogę wyjść i zdobyć zaświadczenia, że jestem Google.Jest to zatem swego rodzaju konwencja (choć wspierana przez formalne mechanizmy), a jeśli założysz własny ośrodek certyfikacji, dystrybucja jego głównych (i pośrednich) certyfikatów daje dokładnie to samo, co dystrybucja certyfikatów innych urzędów certyfikacji: sprawia, że certyfikaty są wydawane przez ten CA zostanie zaakceptowany przez system jako ważny (tj. godny zaufania).

Mówiąc bardziej praktycznie, magazyn zaufania (dla openSSL) to w zasadzie zbiór plików z określoną konwencją nazewnictwa. Zobacz https://www.openssl.org/docs/faq.html#USER5 :

Kiedy certyfikat jest weryfikowany, jego główny urząd certyfikacji musi być „zaufany” przez OpenSSL, co zwykle oznacza, że certyfikat CA musi być umieszczony w katalogu lub pliku, a odpowiedni program skonfigurowany do jego odczytu

Ten katalog to / etc / ssl / certs (są inne, takie jak / etc / pki na RH-like).

https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu#719047 zawiera dalsze omówienie sposobu dodawania certyfikatu do sklepu, ponieważ czy https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate ,

W skrócie update-ca-Certificates automatyzuje proces i jest powszechnie używanym narzędziem.

Nieco dłuższa wersja polega na tym, że certyfikaty muszą być przechowywane przez hash (np. w plikach o nazwie na wyjściu openssl x509 -hash -in cert.pem), aby openSSL mógł efektywnie sprawdzać łańcuchy.

Zobacz , aby uzyskać dodatkowe informacje.

zaktualizowano , aby odpowiedzieć na pytania w komentarzach:

Certyfikat serwera w tej dyskusji jest definiowany jako zaufany lub nie oparty na łańcuchu zaufania. Jeśli zastanowisz się, jak (np.) curl https://google.com działa, jest to trochę łatwiejsze do zrozumienia:

• curl otwiera połączenie TLS z Google, które zwraca certyfikat.
• curl sprawdza ten certyfikat „użytkownika końcowego” – tj. certyfikat serwera i szuka konkretnie wystawcy.
• jeśli wystawca jest „znany” w zaufanego magazynu, pozostała część łańcucha zaufania jest sprawdzana (tj. sprawdzany jest certyfikat wystawcy certyfikatu serwera, a jeśli ma on wystawcę innego niż on sam, to wystawca jest sprawdzany itd.). Certyfikat uważa się za ważny tylko wtedy, gdy można zweryfikować pełny łańcuch zaufania.

Jednak dystrybucja łańcuchów zaufania byłaby absolutnie niepraktyczna, gdyby konieczne było dołączenie certyfikatów użytkownika końcowego. Nie mam żadnych liczb na temat liczby dostępnych witryn internetowych, ale biorąc pod uwagę fakt, że Alexa zapewnia 1 mln najlepszych, można by założyć, że jest to ponad 1 milion.

W pewnym sensie chodzi o łańcuch zaufania: generalnie musisz mieć w pobliżu certyfikaty wystawcy, ale nie potrzebujesz certyfikatów końcowych do dystrybucji, ponieważ mówią one, kto jest wystawcą.

I możesz zweryfikować, że tak nie jest. t kłamstwo, ponieważ możesz sprawdzić klucz publiczny wystawcy (i łańcuch zaufania, który go ustanawia, jest prawidłowym kluczem) i sprawdzić, czy certyfikat użytkownika końcowego (tj. serwera) został rzeczywiście podpisany przez prywatny odpowiednik wystawcy klucz publiczny.

Więc nie, nie powinieneś rozprowadzać certyfikatów użytkowników końcowych, a jedynie łańcuch zaufania – lub, mówiąc prościej: dystrybuować wszystkie certyfikaty, które wygenerujesz, gdzie BasicConstraints (słusznie) powiedz coś co najmniej CA: TRUE. Nie rozpowszechniaj niczego, co nie spełnia tego warunku, ponieważ jest to strata czasu i miejsca na dysku – wszystko, co nie mówi CA: TRUE, można porównać z czymś, co robi.

Komentarze

• Czy to w każdym przypadku oznacza, że klient potrzebuje dostępu do certyfikatu głównego urzędu certyfikacji, czy tylko do certyfikatu CA, którego serwer certyfikat został podpisany przez? Czy nadal całkowicie brakuje mi jakiegoś punktu?
• Aby zweryfikować certyfikat serwera, klienci musieliby mieć dostęp do pełnego łańcucha zaufania dla tego certyfikatu. W przeciwnym razie klient uzna certyfikat za nieprawidłowy lub poprosi użytkownika o jego akceptację. W twoim przypadku wydaje się dość prawdopodobne, że nie konfigurowałbyś punktu dystrybucji dla swoich CA / CRL, więc najprostszym sposobem jest upewnienie się, że twoje certyfikaty znajdują się w / etc / ssl / certs na komputerach klienckich. tl; dr: certyfikat ma ograniczone zastosowanie do ustanawiania zaufania, jeśli możesz ' t ustanowić jego łańcuch zaufania. Aby to ustalić, musisz zweryfikować cały łańcuch. Dlatego udostępniaj cały łańcuch zaufania.
• Czy to oznacza, że jeśli istnieje główny urząd certyfikacji, pośredni urząd certyfikacji i podpisany certyfikat na serwerze, wszystkie trzy z tych certyfikatów muszą być dostępne dla klienta w ramach /etc/ssl/certs katalog? Ponieważ wszystkie one zawierają klucze publiczne?