en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Często zadawane pytania: Na czym polega problem z „entropią numeru seryjnego”, o którym słyszę?

Mogłeś zobaczyć raporty dotyczące problemu, który ma wpływ na wiele urzędów certyfikacji, w tym Apple, Google, GoDaddy i (niestety) SSL.com. Większość z tych firm używa programu o nazwie EJBCA (Enterprise Java Beans Certificate Authority) do szeregu działań urzędów certyfikacji. Jak zauważył dyrektor SSL.com ds. Architektury bezpieczeństwa, Fotis Loukos:

„Metoda generowania numerów seryjnych zastosowana przez EJBCA doprowadziła do rozbieżności między oczekiwanym a rzeczywistym zachowaniem i danymi wyjściowymi, tak że każdy CA używający EJBCA z ustawieniami domyślnymi napotka ten problem (i tym samym będzie naruszał BR 7.1).”

„BR 7.1” odnosi się do sekcji 7.1 podstawowych wymagań forum CA / B, która stanowi:

„Od 30 września 2016 r. CA MUSI generować niesekwencyjne numery seryjne certyfikatów większe od zera (0), zawierające co najmniej 64 bity danych wyjściowych z CSPRNG”.

CSPRNG to skrót od „bezpiecznego kryptograficznie generatora liczb pseudolosowych” i jest to mechanizm używany do generowania liczb o wystarczającej losowości (lub „entropii”), aby zagwarantować, że są bezpieczne i niepowtarzalne. Metoda, którą wybrał EJBCA podczas generowania numerów seryjnych, jednak automatycznie ustawia początkowy bit na zero - co oznacza, że ​​w ciągu 64-bitowym numer seryjny będzie zawierał tylko 63 bity danych wyjściowych z CSPRNG.

Rzeczywisty wpływ tego problemu na bezpieczeństwo jest znikomo mały, ale nawet jeśli różnica między 63 a 64 bitami entropii nie stanowi zagrożenia dla użytkowników Internetu, nadal narusza wymagania, które SSL.com i wszystkie inne renomowane CA przestrzegają. Właśnie dlatego SSL.com unieważnia wszystkie certyfikaty, których dotyczy problem, i wydaje certyfikaty zastępcze dla wszystkich klientów, których dotyczy problem.

Certyfikaty zastępcze będą tego samego typu co certyfikaty odwołane i będą zawierać te same nazwy DNS. Ponadto okres ważności tych certyfikatów zastępczych będzie wynosił pełny czas trwania pierwotnie zakupionego certyfikatu. Oznacza to, że nawet jeśli kupiłeś roczny certyfikat cztery miesiące temu, nowy certyfikat zastępczy będzie ważny przez cały rok od daty wystawienia, co daje łącznie 16 miesięcy.

Wreszcie ten problem ma zastosowanie tylko na SSL.com SSL /TLS certyfikaty (Basic, Premium, High Assurance, Enterprise EV, Wildcard i Multi-domain). Inne rodzaje certyfikatów, w tym S/MIME, NAESB i podpisywanie kodu nie są w żaden sposób naruszane.

Dziękujemy za wybranie SSL.com! W razie jakichkolwiek pytań prosimy o kontakt mailowy pod adresem Support@SSL.com, połączenie 1-877-SSL-SECURElub po prostu kliknij łącze czatu w prawym dolnym rogu tej strony. Odpowiedzi na wiele często zadawanych pytań można również znaleźć w naszym baza wiedzy.

Powiązane FAQ

Bądż na bieżąco

Co to jest SSL /TLS?

Odtwórz wideo

Subskrybuj biuletyn SSL.com

Nie przegap nowych artykułów i aktualizacji z SSL.com