Тази статия ще обясни как да се използват сертификати, издадени от независим сертифициращ орган (CA), като Let's Encrypt, Comodo, Symantec, Digicert и др. Ще обхване и как работят сертификатите като цяло.
Синопсис
Сертификатите служат на две основни цели: Да криптират комуникацията между две обекти и да потвърдят автентичността на обекта. Първият може да бъде предоставен от така наречения самоподписан сертификат, но за удостоверяване на обекта ви е необходим глобално доверен сертификат, издаден от корен или междинен CA. Тази статия ще обясни как сертификатите обикновено постигат това удостоверяване, как да промените формата на сертификата за работа с други устройства, включително нашите защитни стени, как да импортирате сертификата във вашата защитна стена и как трябва да се обработват сертификатите, за да се избегнат рисковете за сигурността.
Съдържание
- Как работи сертификатът?
- Самоподписани сертификати
- Работа със сертификати
- Импортиране на сертификати в USG / ATP защитни стени
- Защита на сертификата
Как работи сертификатът?
Всеки сертификат се състои от две части: Сертификатът (наричан още публичен ключ) и частният ключ. Сертификатът може да бъде публично споделен и съдържа само информация за целите, за които е издаден сертификатът и на кой обект е издаден сертификатът - това може да е вашето FQDN, имейл адрес или друга стойност.
Сертификатите имат ограничен период на валидност - това помага при ситуации, когато някакъв стар сертификат с частен ключ е изкопан някъде след десетилетия. Ако валидността беше безкрайна, сертификатът все още може да се използва за злонамерени цели от всеки, който се докопа до него. От 2021 г. се препоръчва да не се използва период на валидност над една година. С появата на автоматични механизми за преиздаване като CertBot, този период може да стане много по-кратък за допълнително подобряване на сигурността.
Сертификатите могат да бъдат отнети в случай, че частният ключ е изтекъл - и като предпазна мярка, всяко нарушение на сигурността, което компрометира хардуер, съдържащ частни ключове, трябва да бъде последвано от отнемане на сертификат и последващо преиздаване на нови сертификати.
Сертификатите могат да се издават на различни субекти, като FQDN, E-mail, дори IP адрес или дадено име. Въпреки че е технически възможно да имаме заместващи FQDN сертификати и тези често се предпочитат от потребителите, имайте предвид, че в случай на изтичане на частен ключ от конкретна услуга, заместващият сертификат удостоверява цялото FQDN - в резултат на това изтичане на частният ключ на уеб сървър, който се използва само за фирмена презентация, може да се използва и за MITM атаки между Exchange сървър или CRM система. Поддържането на независими сертификати за всеки поддомейн помага за смекчаване на въздействието на изтичането, докато сертификатът не бъде отменен.
Въпреки че е възможно също да се издават сертификати на IP адрес, това не е актуално. Причината за това е, че IP адресите могат лесно да се променят в сравнение с FQDN.
Основният принцип на сертификатите е доста прост. В пример, Алис иска да получи достъп до сървъра на Боб, но проблемът е, че тя никога не е била там, така че те никога не биха могли да обменят някаква обща тайна за удостоверяване. Как може Алис да е сигурна, че всъщност се свързва с Боб? Тук Чарли влиза в игра. Алис познава Чарли и добави сертификата си към хранилището на основните сертификати. Затова Алис смята Чарли за доверен субект. Ако Боб има свой собствен сертификат и частен ключ, издаден от Чарли, той може да удостовери автентичността си на Алис и няма значение, че Алис никога преди това не е била във връзка с Боб, тъй като Боб има доверие от Чарли и тъй като Алис се доверява на Чарли, тя също вярва на Боб . Това е нещо, наречено Верига на доверието.
Нека да разгледаме веригата на доверие за нашия уеб сертификат за поддръжка Campus: 
Забележете, че има и друг обект, наречен R3. Това се нарича Intermediate CA, докато DST Root CA X3 е Root CA. Сертификатът може да има само един корен CA, но може да има и повече междинни CA. Междинният CA е субект, който е получил разрешение да издава сертификати за своите клиенти. Докато вашият компютър има DST Root CA X3 сертификат в списъка с надеждни коренни сертификати, той ще счита, че support.zyxel.eu е доверен.
Самоподписани сертификати
По подразбиране нашите защитни стени (и много други устройства) използват самоподписани сертификати за установяване на криптирана TLS връзка. Такъв сертификат се отчита чрез добре познато съобщение за грешка от браузъра: 
Има две причини, поради които това се случва. Първата причина е, че сертификатът е основно сертификат на root CA, който не присъства във вашата система. Но просто инсталирането му като root CA на вашия компютър няма да свърши работа, защото сертификатът не е издаден за вашия IP или домейн. Сертификатът обаче е подходящ за сигурна връзка и използването му не представлява никакъв риск за сигурността, стига частният му ключ да не изтече - единственият проблем тук е, че самоличността не може да бъде потвърдена.
Работа със сертификати
През годините бяха разработени много формати на сертификати. Сертификатите обаче все още използват същия принцип и всички формати могат да бъдат конвертирани в други формати.
Формати на сертификати
Най-старият формат би бил PEM, който съдържа кодирания ASCII ключ. Причината за това е оригиналната употреба в криптирани имейли, където бинарният сертификат може да бъде неправилно оформен. PEM са често срещани в системите на Unix и е вероятно вашият CA да ви е изпратил сертификат заедно с частен ключ във формат PEM. Обикновено използва .pem или .cer разширение на файла.
DER е двоична форма на сертификат за формат ASCII PEM. Всички видове сертификати и частни ключове могат да бъдат кодирани във формат DER. Този формат поддържа съхранението на един сертификат и не включва частен ключ за междинния / корен CA. Те имат разширение .der или .cer и най-често се използват на Java платформи.
PKCS # 7 е двоичен формат, който позволява да се съдържат сертификати или цяла сертификационна верига на доверие в един файл. Нито един частен ключ не може да се съхранява в този формат. Този формат най-често се използва от CA за осигуряване на пълна верига на доверие. Използва разширение .p7b.
PKCS # 12, известен също като PFX, е формат, който може да съдържа цялата верига на доверие и частния ключ. Обикновено този формат се предоставя от CA, тъй като може да бъде защитен с парола. Обикновено използва разширение .p12 или .pfx.
Сертификатни инструменти
Windows има вградена системна помощна програма CLI certutil, която може да се използва за конвертиране на сертификати. Приставките за управление в Microsoft Management Console също позволяват управление на сертификати.
Помощната програма с отворен код, наречена OpenSSL, също е в състояние да обработва и конвертира сертификати. Налични са двоични файлове за Windows, Linux и macOS (и много други платформи)
Полезни команди на certutil:
Merging PEM into PFX:
C:\temp>certutil –MergePFX cert.cer cert.pfx
NOTE: as certutil doesn't allow to specify private key path, the key must be present
in the same directory as certificate, have the same name and .key extension.
Полезни команди на OpenSSL:
Merging PEM into PFX:
C:\temp>openssl pkcs12 -export -out cert.pfx -inkey key.pem -in cert.pem
Импортиране на сертификат в защитни стени USG / ATP
Настоящият дизайн (от юни 2021 г.) е ограничен до внос на сертификати без междинни ключове. Ако сертификатът съдържа междинен ключ, файлът ще бъде анализиран неправилно и опитът да се използва такъв сертификат може да доведе до липса на услуга (като WebGUI). Добра идея е да получите сертификата във формат .pem и да го експортирате във формат .pfx, използвайки certutil или OpenSSL. Сертификатът може да бъде импортиран, заедно с паролата му в следното меню:
Configuration > Objects > Certificates > My Certificates
Защита на сертификата
Всеки сертификат има съответния частен ключ. Докато сертификатът е публична информация, частният ключ трябва да се обработва като тайна - и не трябва да се споделя от никого. Дори и при нас в Zyxel - единственият валиден начин е да се използват инструменти за отдалечена помощ като TeamViewer. Когато съхранявате частния ключ във формат pem, проверете отново разрешенията за достъп до частния ключ, за да предотвратите изтичането му. Винаги използвайте криптиране с парола във формат pfx, за да осигурите поне известна степен на сигурност при експортиране на сертификати. Всички сертификати с изтекъл частен ключ трябва да бъдат отменени незабавно.
ОПРОВЕРЖЕНИЕ:
Уважаеми клиенти, моля, имайте предвид, че ние използваме машинен превод, за да предоставяме статии на вашия местен език. Не всички текстове могат да бъдат преведени точно. Ако има въпроси или несъответствия относно точността на информацията в преведената версия, моля, прегледайте оригиналната статия тук: Оригинална версия