Ludzie mawiali -
cer - certyfikat przechowywany w standardowym formacie X.509. Ten certyfikat zawiera informacje o właścicielu certyfikatu ... wraz z kluczami publicznymi i prywatnymi.
pfx - oznacza format wymiany osobistej. Służy do wymiany obiektów publicznych i prywatnych w jednym pliku. Plik pfx można utworzyć z pliku .cer. Może również służyć do tworzenia certyfikatu wydawcy oprogramowania.
** otrzymałem referencję z tego linku Jaka jest różnica między plikiem cer, pvk i pfx? **
ale nikt nie mówi, kiedy powinniśmy używać pliku CERT, a kiedy PFX. Jeśli to możliwe, przedyskutuj sytuację, kiedy powinniśmy wybrać plik CERT i kiedy powinniśmy sięgnąć po plik PFX. Dzięki.
ssl
certificate
Tomasz
źródło
źródło
Odpowiedzi:
Plik .pfx zawiera zarówno publiczny, jak i prywatny klucz powiązany z certyfikatem (NIGDY nie udostępniaj tego poza swoją organizację); może być używany do TLS / SSL na stronie internetowej, do cyfrowego podpisywania wiadomości lub tokenów autoryzacyjnych lub do uwierzytelniania w systemie partnerskim. Plik .cer zawiera tylko klucz publiczny (jest to typowy plik wymieniany z partnerami integracyjnymi); może służyć do weryfikacji tokenów lub żądań uwierzytelnienia klienta i właśnie to jest odbierane przez klienta HTTP z serwera podczas uzgadniania SSL.
źródło
2 x scenariusze, które działają nieco inaczej:
SCENARIUSZ 1:
Przeglądarka internetowa (klient) uzyskuje dostęp do strony internetowej (serwera) przez HTTPS przy użyciu SSL.
Serwer ma plik .PFX zawierający oba klucze. Klient łączy się ze stroną internetową na serwerze, a serwer wysyła kopię swojego klucza publicznego (plik .CER) do klienta w ramach uzgadniania SSL. Klient następnie generuje „SESSION-Key” i szyfruje go przy użyciu klucza publicznego otrzymanego z serwera. Klucz sesji jest następnie przesyłany z powrotem do serwera i odszyfrowany w celu potwierdzenia jego autentyczności. Jeśli się powiedzie, zarówno klient, jak i serwer współdzielą teraz „klucz sesji” do komunikacji przy użyciu szyfrowania symetrycznego (tj. Zarówno klient, jak i serwer, teraz oba szyfrują ORAZ deszyfrują wszystkie wiadomości między sobą przy użyciu tego samego klucza sesji. wykonywana za kulisami w tle przeglądarki internetowej, między momentem wprowadzenia adresu URL w pasku adresu, a wyświetleniem strony internetowej.
SCENARIUSZ 2:
Aplikacja (klient) łączy się z witryną FTP (serwerem)
lub
pulpitem zdalnym (klient do serwera) za pomocą protokołu SSH
(zastosowanie mają oba przykłady)
W tym scenariuszu, zarówno Klient i serwer będzie mieć własne prywatne i publiczne par klucz
(w przeciwieństwie do innych przykładów wymienionych w tym wątku, że tylko wyjaśnić, gdy serwer ma oba klawisze, a klient ma tylko klucz publiczny)
Teraz, dla celów wyjaśnienia - oznaczmy pary kluczy w następujący sposób:
A1 i A2 = odpowiednio klucze prywatne i publiczne serwerów
B1 i B2 = odpowiednio klucze prywatne i publiczne klientów
Korzystając z tego modelu, poprzednie posty w tym wątku mówiły o tym, kiedy serwer ma A1 i A2 ( plik .PFX ) i udostępnia klientom tylko kopię A2 ( .CER )
Podczas gdy połączenia FTP lub SSH (istnieją inne przykłady) składają się z kluczy A1 , A2 , B1 i B2 w całej komunikacji klient-serwer. Na przykład
- Klient łączy się z serwerem FTP.
- Serwer wysyła kopię swojego klucza publicznego (A2) do klienta.
- Klient wysyła swój własny klucz publiczny (B2) z powrotem do serwera, kończąc uzgadnianie.
- Będzie to teraz używać szyfrowania asymetrycznego
Serwer ma teraz A1 ( własny prywatny ), A2 ( własny publiczny ), a kopia B2 ( publiczny
klienta ). Klient ma teraz B1 ( własny prywatny ), B2 ( własny publiczny ) i kopię A1 ( serwer Publiczne )
Komunikacja
klient -serwer: klient używa A2 (klucz publiczny serwera) do szyfrowania wiadomości przypisanych do serwera, serwer odszyfrowuje je za pomocą A1 (klucz prywatny serwera)
Komunikacja między
serwerem a klientem: serwer używa B2 (klucz publiczny klienta) do szyfrowania wiadomości przypisanej do klienta, klient odszyfrowuje je przy użyciu B1 (klucz prywatny klienta)
Jeśli chodzi o typy plików .CER i .PFX, serwer będzie miał własny plik .PFX, który nie powinien być rozpowszechniany poza organizację, zamiast tego należy rozesłać plik .CER do klientów.
więcej informacji można znaleźć tutaj:
https://www.digicert.com/ssl-cryptography.htm
i tutaj:
/server/107433/why-does-a-ssh-public-key-sit-on-the-server-and-not-with-the-client
źródło
Z mojego doświadczenia (nie jest tak rozległy, jak chcę), używam pliku pfx podczas konfigurowania powiązania https na serwerze IIS (ponieważ zawiera on zarówno klucz publiczny, jak i prywatny, wystarczy ten plik), plik cer jest po prostu publiczną częścią pary kluczy (w większości przypadków) i musisz go używać w połączeniu z plikiem .key podczas konfigurowania ruchu ssl na serwerze nginx lub apache,
O ile rozumiem, nie ma już trudniejszych powodów, by używać jednego lub drugiego,
źródło
Jak już wspomniano, chodzi o trochę jabłek i pomarańczy, ponieważ plik cer jest tylko kluczem publicznym, ale plik pfx zawiera zarówno klucze publiczne, jak i prywatne.
Więc bardziej sprawiedliwe byłoby pytanie, kiedy chcesz użyć pliku pfx, a nie pliku pem. Biorąc pod uwagę, że pliki pfx były krytykowane za zbytnie skomplikowane, uczciwą odpowiedzią na twoje drugie pytanie może być: zawsze chciałbyś użyć pliku pfx tylko wtedy, gdy używasz IIS, a jego konfiguracja absolutnie nie pozwoli ci użyć niczego innego .
Źródło: https://en.wikipedia.org/wiki/PKCS_12 (Odnośny przypis to artykuł Petera Gutmanna).
źródło
SSL wykorzystuje szyfrowanie asynchroniczne, co oznacza, że jeden klucz (klucz prywatny) jest przekazywany serwerowi, który „jest właścicielem” pary kluczy, podczas gdy drugi klucz (klucz publiczny) jest dystrybuowany swobodnie.
Nazywa się to asynchronicznym, ponieważ dane zaszyfrowane kluczem prywatnym można odszyfrować tylko za pomocą klucza publicznego, podczas gdy dane zaszyfrowane kluczem publicznym można odszyfrować tylko za pomocą klucza prywatnego. Jeśli więc chcesz wysłać coś bezpiecznie do właściciela, zaszyfrujesz to jego kluczem prywatnym, a on będzie jedynym, który może to odszyfrować. Jeśli właściciel chce udowodnić, że coś wysłał, szyfruje to kluczem prywatnym i każdy, kto ma klucz publiczny, może to odszyfrować. (Po zainstalowaniu certyfikatów odbywa się to zwykle za kulisami za pomocą przeglądarki lub narzędzia poczty e-mail).
Ponieważ właściciel chce zachować ten klucz prywatny jako prywatny, będzie on chroniony hasłem i przekazany TYLKO serwerowi będącemu właścicielem (często w pliku PFX lub P12). Ale klucz publiczny będzie rozpowszechniany swobodnie (często w pliku CER).
źródło