SSL Валидатор за Заявки за Подписване на Сертификати
Използването на CSR Проверка е много просто:
CSR Проверка се използва в различни сценарии за получаване и управление на SSL/TLS сертификати:
Преди да изпратите CSR до Сертифициращ Орган (CA), проверете дали Общото Име (домейн име), име на организацията и държавен код са въведени правилно. Издаването на сертификат с неправилна информация може да доведе до скъпо и отнемащо време преиздаване.
След генериране на CSR с помощта на OpenSSL или панел за управление на сървъра, потвърдете, че съдържа очакваното съдържание. Особено за SANs (Алтернативни Имена на Субекта) или wildcard сертификати, проверете дали множество домейни са правилно включени.
Проверете съответствието със сигурностните политики. Например, проверете дали се използва RSA 2048-бита или по-висока, или ECDSA (Елиптична Крива Криптография), както се изисква.
Когато изтичането на SSL сертификата наближава и се генерира CSR за подновяване, проверете дали е включена същата информация (име на организацията, име на отдела и др.) като предишния сертификат.
Когато се генерират различни CSR на множество уеб сървъри или балансьори на натоварване, идентифицирайте кой CSR е за кой сървър чрез проверка на съдържанието на CSR.
Когато възникнат грешки при инсталиране на сертификат или предупреждения в браузъра, проверете дали съдържанието на CSR и сертификата съвпадат. Несъответствия в Общото Име или SANs са чести причини.
Когато сигурностни одити или изисквания за съответствие налагат отчитане на алгоритъма на публичния ключ или дължината на ключа на използваните сертификати, извлечете тази информация от CSR.
CSR (Заявка за Подписване на Сертификат) е електронни данни, изпратени до Сертифициращ Орган (CA) при получаване на SSL/TLS сертификат. CSR съдържа информация, която да бъде включена в сертификата (домейн име, име на организацията, местоположение и др.) и публичния ключ.
CSR включва следната информация:
CSR се основават на криптография с публичен ключ:
CSR могат да бъдат генерирани с помощта на следните инструменти:
Пример: openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr
CSR обикновено са кодирани във формат PEM (Privacy Enhanced Mail). Това е Base64-кодиран текст в следния формат:
-----BEGIN CERTIFICATE REQUEST----- MIICvDCCAaQCAQAwdzELMAkGA1UEBhMCVVMxDTALBgNVBAgMBFV0YWgxDzANBgNV ... -----END CERTIFICATE REQUEST-----
Като проверите, че Общото Име и информацията за организацията са правилни, преди да изпратите CSR до CA, можете да намалите разходите за преиздаване на сертификати.
Проверете дали се използва изискваната дължина на ключа (напр. RSA 2048-бита или по-висока) или алгоритъм (препоръчва се ECDSA), посочен в сигурностната политика на вашата организация.
Когато възникнат грешки при инсталиране на сертификат или предупреждения в браузъра, бързо идентифицирайте причината чрез проверка на съдържанието на CSR.
За wildcard или multi-domain сертификати, проверете дали Алтернативните Имена на Субекта (SANs) са правилно включени.
Не е нужно да запомняте команди на OpenSSL; лесно проверете съдържанието на CSR във вашия браузър.
CSR данните се обработват в браузъра и не се изпращат до сървъри, позволявайки безопасна проверка на чувствителна информация.
Докато CSR съдържат само публични ключове, никога не излагайте частни ключове външно. Ако частен ключ бъде компрометиран, SSL сертификатът става невалиден и комуникацията може да бъде прихваната.
Текущите стандарти изискват RSA 2048-бита или по-висока, или ECDSA (Елиптична Крива Криптография). RSA 1024-бита е остаряла.
Препоръчва се да генерирате нов CSR и частен ключ за всяко подновяване на сертификат. Продължаващото използване на стари частни ключове увеличава риска от компрометиране.
Общото Име (CN) трябва точно да съвпада с домейн името, където ще се използва сертификатът. Например, www.example.com и example.com се третират като различни домейни.
Wildcard сертификатите (*.example.com) са валидни за поддомейни (sub.example.com), но НЕ за основния домейн (example.com).
CSR е като 'формуляр за кандидатстване', изпратен до CA за получаване на сертификат. CA проверява съдържанието на CSR, цифрово го подписва и издава SSL сертификата. CSR съдържа публичния ключ, докато SSL сертификатът съдържа както публичния ключ, така и подписа на CA.
Не, частните ключове НЕ са включени в CSR. CSR съдържат само публични ключове. Този инструмент само анализира съдържанието на CSR и не може да получи достъп до частни ключове.
Да, ако сте генерирали CSR с неправилна информация (Общо Име, име на организацията и др.), трябва да го регенерирате с правилна информация. Издаването на сертификат с неправилен CSR може да доведе до допълнителни такси за преиздаване.
Посочете Общото Име със звездичка (*), като '*.example.com'. Това ще издаде сертификат, валиден за всички поддомейни като sub.example.com, www.example.com и др.
Самите CSR нямат срок на годност, но от гледна точка на сигурността се препоръчва да ги използвате веднага след генерирането. CSR, оставени неизползвани за дълги периоди, увеличават риска от компрометиране на частния ключ, така че се препоръчва регенериране.
SANs са функция за разширение за покриване на множество домейн имена с един SSL сертификат. Например, един сертификат може да покрива www.example.com, example.com и mail.example.com.
Не, този инструмент е за проверка и анализ на съдържанието на CSR. За генериране на CSR използвайте OpenSSL или панели за управление на сървъра.
ECDSA (Елиптична Крива Криптография) осигурява еквивалентна сигурност с по-къси дължини на ключовете от RSA. Например, ECDSA 256-бита е равна на RSA 3072-бита. Въпреки това, по-старите браузъри и системи може да не го поддържат, така че ако съвместимостта е важна, изберете RSA 2048-бита или по-висока.