Muszę utworzyć CSR dla wieloznacznego certyfikatu SSL. Niektóre często zadawane pytania od dostawców SSL mówią, że powinienem wygenerować plik CSR na komputerze, na którym chcę zainstalować certyfikat? Rozumiem, że nie powinno mieć znaczenia, gdzie wygeneruję CSR lub plik klucza, o ile później przeniosę pliki do właściwej lokalizacji.
Więc moje pytanie brzmi: czy ma znaczenie, gdzie generowane są pliki CSR i pliki kluczy do certyfikacji SSL?
Odpowiedzi:
Twoje zrozumienie jest prawidłowe. Wszystkie inne rzeczy są równe, to nie ma znaczenia; ale są zmarszczki.
Jedną z zalet generowania ich na danym serwerze jest to, że minimalizuje to ryzyko naruszenia klucza podczas transportu. Tak długo, jak używasz bezpiecznej maszyny do ich wygenerowania i bezpiecznej metody (odpornej na ataki MITM), aby przenieść je na serwer, uciekniesz przed tym. Nie zapomnij o bezpiecznym skasowaniu ich w systemie generującym, chyba że celowo zamierzasz zachować kopie i jesteś odpowiednio zabezpieczony.
Jedną zaletą generowania na osobnym komputerze: zwykle jest to pulpit. Pula entropii na komputerze stacjonarnym jest prawie zawsze głębsza niż na serwerze nienadzorowanym, ponieważ pulpit ma duże źródło losowości połączone za pomocą kabli klawiatury i myszy (tj. Ty!). Niedobór entropii może powodować, że generowanie kluczy zajmuje dużo czasu, lub może /dev/urandomzamiast tego używać wyjścia PRNG, w zależności od paranoi narzędzia generującego, a to może prowadzić do słabszych kluczy; komputery stacjonarne zwykle nie mają tego problemu.
Późniejsza edycja : zgodnie z dyskusją prowadzoną gdzie indziej tutaj, podniesiono dwa punkty. Po pierwsze, można przejść na pół-way domu przez generowanie entropię na pulpicie na przykład dd if=/dev/random bs=1k count=10 of=/tmp/entropy.dat, kopiowanie , że do zdalnego serwera, a wprowadzenie go do procesu generowania klucza bezpośrednio lub poprzez pogłębienie entropii basen zdalnego serwera. Nie znalazłem jeszcze sposobu na zrobienie tego pierwszego, a wykonanie tego drugiego wymaga na ogół przywileju, który - jeśli kanał między tobą a serwerem zdalnym nie jest bezpieczny, co jest raczej celem całego sprzeciwu - jest również niepewny.
Po drugie, szacunkowy mjg59 podnosi kwestię sprzętowych modułów bezpieczeństwa - to znaczy urządzeń, w które wkładasz lub w których tworzysz klucze prywatne, i które następnie wykonują operacje klawiszy bez wypuszczania klucza. To doskonały punkt, ale poza zakresem tego pytania.
Ale bardziej ogólny wynik wątku - że powinieneś mieć dokładny model zagrożenia i odpowiednio wybierać swoje odpowiedzi - jest dobry. Mój model zagrożenia polega na tym, że moje kanały komunikacji są bezpieczne, ale moje punkty końcowe są atakowane inteligentnie. Oznacza to, że wygeneruję lokalnie silne pary kluczy SSL i rozpowszechnię je. Jeśli okaże się, że mój model jest niedokładny, a moje komunikacje okażą się podatne na atak, od razu będę wiedział, że zakładam, że wszystkie moje pary kluczy SSL są zagrożone. Jeśli twój model zagrożenia jest inny, powinieneś odpowiednio dostosować swoje praktyki.
To ma znaczenie.
Jeśli wygenerujesz je na innym komputerze, klucze są wrażliwe na komputerze generującym, a następnie na serwerze. Jeśli używasz zainfekowanej maszyny do ich wygenerowania, niektóre wirusy mogą ukraść klucze, nawet zanim zostaną przeniesione na bezpieczny serwer.
Jeśli wygenerujesz je na bezpiecznym serwerze i po prostu przeniesiesz CSR / cert, szanse, że ktoś / coś zdobędzie klucz prywatny, są mniejsze niż w pierwszym przypadku, ponieważ klucz prywatny znajduje się tylko na jednym komputerze.