Удостоверяване на цифров сертификат в Windows PKI, Windows IT Pro
За да извърши удостоверяване на сертификат, едно PKI приложение трябва да внедри подходяща логика, която изпълнява поредица от процедури за съпоставяне за различните части на сертификата. В тази статия ще разгледаме тези процедури, както и други аспекти на процеса на удостоверяване на сертификата. Внимателното проучване на този процес ще ви помогне допълнително да разпознаете и разрешите проблеми с валидирането на сертификата, ако възникнат.
Сравнителни процедури
В процеса на удостоверяване на сертификата се извършват процедури за проверка за него по следните критерии: цифров подпис, параметри на доверителната връзка (trust), времеви параметри (time), информация за анулиране на сертификат (revocation) и параметри на формата (formatting). Ако се окаже, че сертификатът не отговаря на изискванията на поне един от тези критерии, тогава той се счита за невалиден. При проверката на цифров подпис автентификаторът използва доверен публичен ключ, за да провери автентичността на цифровия подпис, добавен към сертификата от издаващия Сертифициращ орган (CA). Ключът е публичният ключ на CA, който е издал сертификата, или друг орган, включен във веригата от сертификати вв съответствие с йерархичния модел на доверителните отношения.
За да проверите автентичността на един подпис, не е достатъчно само да имате публичен ключ, той трябва да бъде надежден. В Windows Server 2003 и Windows 2000 Server PKI инфраструктури, сертификатът и публичният ключ на напълно надежден CA се наричат доверителни котви и са достъпни чрез контейнера Trusted Root Certification Authorities на клиентското хранилище на Windows PKI сертификати. Процесът на проверка на доверието удостоверява сертификата на доверените CA, известен също като удостоверяване на веригата на сертификати. Изпълнението на тази процедура може да задейства различни цикли на удостоверяване за всеки сертификат във веригата. Процедурата за удостоверяване на веригата от сертификати ще бъде разгледана по-подробно по-долу.
При обработка на параметрите на временния сертификат текущата дата се сравнява с началната и крайната дата на сертификата. Една от причините за ограничаване на валидността на сертификата е спазването на съвременните изисквания за компютърна сигурност, по-специално на криптографията, тъй като е малко вероятно някой да се довери на сертификати, издадени с помощта на остаряла технология.
Стандартна процедура за обработка на верига от сертификати
Какво е верига от сертификати и защо трябва да се използва в процеса на удостоверяване на сертификат? Чрез изграждането на верига можете да организирате удостоверяването на всички сертификати, с които е свързан този сертификат. За да разберем какво е верига от сертификати, нека разгледаме йерархичния модел на доверие в PKI инфраструктура. В този модел (който също еобсъдени в принципите на доверие на PKI, споменати по-горе), веригата от сертификати на всеки потребител се състои от сертификатите на всички CA, които образуват пътя от потребителя до основния CA в йерархията. Когато използвате йерархичен модел на доверие, всеки сертификат съдържа указател към родителския (или издателя на сертификата) CA, който се съхранява в полето за издател на сертификата X.509. На фиг. Фигура 1 показва примерна верига за потребителски сертификат, издаден от CA, когато има йерархия на две нива в PKI инфраструктура. Ориз. 1 илюстрира най-простия пример за използване на параметрите субект (субект) и издател на сертификат (издател на сертификат). В този пример субектът на потребителския сертификат е потребителят, а издателят на сертификата е междинният CA. В сертификат на междинен център субектът е самият център, докато издателят в този случай ще бъде основният CA. В йерархичен модел на доверие основният CA винаги подписва собствения си сертификат, така че той е едновременно субект и издател на сертификата за своя сертификат.
Изграждане на верига от сертификати. На този етап програмата за проверка преглежда цялата верига от сертификати, започвайки със сертификата на потребителя. Това търси сертификат, който е абсолютно доверен от CA (т.е. котва за доверие). В примера, показан на фиг. 2, автентификаторът е намерил доверителната котва на основно ниво на CA, въпреки че по принцип може да бъде на междинно ниво на CA. След като котвата на доверието бъде намерена, процедурата за изграждане на веригата е завършена, след което логиката на програмата за проверка преминава към процедуратаверижно удостоверяване на сертификати. Ако верификаторът не успее да намери надеждната котва, тогава цялата обработка на веригата се прекратява и за удостоверителя става невъзможно да реши дали да се довери на сертификата.
Разширението на идентификатора на ключа на органа (AKI) на сертификата, който се проверява, се използва за идентифициране на CA сертификата по време на процедурата за удостоверяване на веригата. Полето AKI съдържа следните видове информация.
- Името на органа, издал сертификата, и серийния номер на сертификата на този орган. Ако тази информация присъства в полето AKI, тогава удостоверителят търси съвпадащ сертификат, като използва полетата Сериен номер и Тема. Този метод за идентифициране на сертификат се нарича силно съвпадение.
- Идентификатор на публичен ключ (KeyID) на сертификата на органа, издал проверявания сертификат. Ако тази информация присъства в полето AKI, тогава автентификаторът търси съвпадащ сертификат, използвайки разширението на сертификата Subject Key Identifier (SKI), което съхранява уникалния идентификатор на публичния ключ на предметния сертификат. Този метод за идентифициране на сертификат се нарича съвпадение на ключ.
Ако няма AKI поле в валидирания сертификат, автентификаторът се опитва да идентифицира издаващия CA сертификат, като проверява дали името, взето от полето Issuer на сертификата в процес на валидиране, съответства на съдържанието на полето Subject на сертификата. Този метод за идентифициране на сертификат се нарича съпоставяне на имена.
В случаите, когато сертификатът, който се проверява, не е достъпен локално, софтуерът за удостоверяване на Windows използва разширението за информация за органа.Access (AIA), за да получите копие на сертификата, като го изтеглите по мрежата от съответния сайт. За да направите това, използвайте полето AIA, което съдържа указател към възела за съхранение на CA сертификати за протоколи FTP, HTTP, Lightweight Directory Access Protocol (LDAP) или указател към съответния споделен файл. Ако AIA поле съдържа множество връзки, софтуерът за удостоверяване се опитва да използва всички тези връзки в реда, в който са изброени в полето. Всички сертификати, които се зареждат с помощта на полето AIA, се кешират от валидатора в PKI потребителския профил на локалното устройство (а именно в папката Documents and SettingsusernameLocal SettingsTemporary Internet Files), както и в локалното хранилище на сертификати на потребителя.
Можете да видите веригата, свързана с конкретен сертификат, като използвате раздела Certification Path на диалоговия прозорец със свойства на сертификата, който се показва на екрана. За да получите достъп до всички ваши сертификати, трябва да стартирате конзолната добавка Certificates MMC, а за достъп до свойствата на отделен сертификат щракнете двукратно върху съответния сертификат в списъка на конзолната добавка.
Ако използвате уеб интерфейса на Windows 2003 или Windows 2000 Server CA за изтегляне на сертификата, можете да изберете да изтеглите само самия сертификат или да изтеглите сертификата заедно с всички сертификати във веригата. Възможността за изтегляне на верига от сертификати понякога е много полезна, например, ако използвате лаптоп за работа. В този случай всички сертификати във веригата ще бъдат достъпни за автентификатора дори когато потребителят е на път.
Обработка на веригата от CTL
Тази процедура е специален случай на обработка на вериги от сертификати. CTL съдържа сертифициран списък от сертификати, които са абсолютно надеждни от главните CA, и следователно съдържа самоподписани CA сертификати. Формирането на CTL списъка се извършва чрез падащото меню на контейнера на Enterprise Trust Group Policy Object. Този контейнер се осъществява чрез последователно избиране на Настройки на Windows Настройки за сигурност Правила за публичен ключ. GPO също така автоматично зареждат CTL в контейнера Enterprise Trust на хранилището за съдържание на сертификати. Обърнете внимание, че контейнерът Enterprise Trust не е контейнер за закрепване на доверие - неговото съдържание не се счита за абсолютно надеждно по подразбиране.
Обработка на веригата за кръстосани сертификати
Кръстосаното сертифициране е нова възможност за доверие, въведена в Windows 2003 PKI (за повече информация вижте Принципите на доверие на PKI). За разлика от CTL, кръстосаното сертифициране ви позволява да установите фини PKI доверие между различни CA инфраструктури. При установяване на доверителна връзка чрез кръстосано сертифициране между два CA, които са част от инфраструктурите на различни организации, всеки от тези центрове става едновременно родител и подчинен, докато много интересни ефекти се наблюдават в процеса на изграждане на вериги от сертификати.
Удостоверяването на сертификати е доста сложна тема, така че ако имате проблеми със сертификатите, познаването на основните принципи на удостоверяване на сертификати в среда на Windows може да ви помогне да изолирате възможните причини и до известна степенулесняват решаването на проблеми.
Жан дьо Клерк ([email protected]) е член на Службата за сигурност на HP. Специализира в управлението на идентичността и сигурността в продуктите на Microsoft. Автор на Инфраструктури за сигурност на Windows Server 2003 (Digital Press)
Споделяйте материал с колеги и приятели