Браузъри и валидиране на сертификат

Въведение

HTTPS (чрез SSL /TLS) използва криптиране с публичен ключ за защита на комуникациите в браузъра от четене или промяна при транзит през Интернет. Сървърите предоставят на посещаващите браузъри публичен ключ, който се използва за установяване на криптирана връзка за всички последващи обмени на данни.

Само че получаването на a работа публичният ключ сам по себе си не гарантира, че той (и чрез разширението на сървъра) наистина е собственост на правилното дистанционно предмет (т.е. лице, фирма или организация). Човек-в-средата нападателите могат да манипулират мрежи, за да обслужват собствените си ключове, като по този начин компрометират всяка комуникация.

Браузърите предотвратяват това чрез при удостоверяването HTTPS сървъри, използващи сертификати, които са цифрови документи, които обвърже публичен ключ към отделен субект. Свързването се потвърждава чрез наличието на доверен ключсертифициращ орган (CA), като например SSL.com проверка на самоличността на потенциалните собственици на сертификати чрез автоматизирани и ръчни проверки на квалифицирани бази данни.

Тази доверителна връзка означава, че сигурността на уеб потребителите не е абсолютна; по-скоро тя изисква потребителите да се доверяват на браузърите и CA, за да защитят сигурността си. Следователно е в интерес на всеки потребител да има основно разбиране за това как работи валидирането на сертификати.

Обърнете внимание, че процесът на валидиране на сертификата (описан подробно в стандартния документ RFC 5280) е доста объркан. В тази статия ще се опитаме да ви преведем по един път (браузър, утвърждаващ SSL на хоста /TLS сертификат) и се придвижвайте в минали сложни детайли, които са несъществени за повечето потребители.

Забележка: Към 2024 август м.г. RFC 9618, документ на Работната група по интернет инженерство (IETF), актуализира алгоритъма за валидиране на ограниченията на политиките в цифровите сертификати X.509 от RFC 5280.

Сертификати и формат X.509

Сертификатите са цифрови файлове във всяко отношение, което означава, че те трябва да следват файлов формат, за да съхраняват информация (напр. подписи, ключове, издатели и др.). Докато частните PKI конфигурациите могат да внедрят всеки формат за своите сертификати, публично доверени PKIs (т.е. тези, на които браузърите се доверяват) трябва да отговарят на RFC 5280, който изисква използването на X.509 v3 формат.

X.509 v3 позволява на сертификатите да включват допълнителни данни, като например ограничения за използване или информация за политиката разширения, като всяко разширение е едно или друго критичен or некритични. Ако клиентът срещне неразпознато некритично разширение, той може да го игнорира. Ако разширението е критично и не е разпознато или не може да бъде обработено, сертификатът трябва да бъде отхвърлен.

Пътеки за сертифициране и обработка на пътя

Сертификатните органи използват частен ключ, за да подпишат криптографски всички издадени сертификати. Такива подписи могат криптографски доказва, че сертификатът е издаден от конкретен CA и че не е бил променян след подписването му.

Отговорните органи установяват собствеността върху своя ключ за подпис, като притежават сертификат за самостоятелно издаване (наречен корен) за съответния публичен ключ. Сертификатните органи (CA) трябва да спазват строго контролирани и одитирани процедури за създаване, управление и използване на root домейн, а за да сведат до минимум експозицията, те обикновено използват root домейн за издаване. междинен сертификати. Тези междинни продукти могат да бъдат използвани за издаване на сертификати на техните клиенти. Сертификатът на коренния CA е самоподписан, а частният ключ е защитен при строги процедури. Издаването обикновено се извършва чрез посредници, а не директно от кореновите центрове.

Браузърите се доставят с вграден списък с надеждни корени. (Това са корени от CA, които са преминали строгите критерии на браузъра за включване.) За да провери сертификат, браузърът ще получи поредица от сертификати, всеки от които е подписал следващия сертификат в последователността, свързвайки корена на подписващия CA към сървъра удостоверение.

Тази последователност на сертификати се нарича a сертификационен път. Коренът на пътя се нарича a доверете се котва и сертификатът на сървъра се нарича листо or крайно образувание сертификат.

Пътно строителство

Често уеб браузърите и софтуерните клиенти като цяло могат да изграждат до множество кандидат-котви за доверие (например поради кръстосани знаци) и често извличат липсващи междинни продукти чрез AIA, за да завършат веригата. Въпреки че един път може да съдържа сертификати, които правилно се „свързват“ с известна котва, самият път може да бъде отхвърлен поради ограничения върху дължината на пътя, името на домейна, използването на сертификата или политиката.

Конструирането и оценяването на всички възможни пътища е скъп процес, изпълняван за всеки нов сертификат, с който браузър се сблъсква. Браузърите са внедрили различни оптимизации, за да сведат до минимум броя на отхвърлените пътеки за кандидат, но задълбочаването на такива подробности е далеч извън обхвата на тази статия.

Валидиране на пътя

След изграждането на път за сертифициране на кандидат, браузърите го валидират, използвайки информация, съдържаща се в сертификатите. Път е валиден, ако браузърите могат да докажат криптографски, че като се започне от сертификат, директно подписан от доверителен котва, съответният частен ключ на всеки сертификат е бил използван за издаване на следващия в пътя, чак до сертификата на листа.

Базовите изисквания изискват имената на субекта и издателя да са посочени всички възможни пътища be идентичен байт по байт, което опростява надеждното изграждане на пътища.

Алгоритъм за валидиране на пътя на сертифициране

Както беше отбелязано по-рано, към август 2024 г. RFC 9618, документ на Работната група по интернет инженерство (IETF), актуализира алгоритъма за валидиране на ограниченията на политиките в цифровите сертификати X.509 от RFC 5280. По принцип браузърите преминават през всички сертификати в пътя, започвайки с доверителната котва (т.е. коренния сертификат), валидирайки основната информация и критичните разширения на всеки сертификат.

Ако процедурата приключи с последния сертификат в пътя без грешки, тогава пътят се приема като валиден. Ако се генерират грешки, пътят се маркира като невалиден.

Основна обработка на сертификати

Независимо от разширенията, браузърите трябва винаги да проверяват основна информация за сертификата, като подпис или издател. Следващите раздели показват последователността на проверките, които браузърите извършват.

1. Браузърът проверява целостта на сертификата

- подпис върху сертификата може да се провери с помощта на нормална криптография с публичен ключ. Ако подписът е невалиден, сертификатът се счита за модифициран след издаването му и следователно се отхвърля.

2. Браузърът проверява валидността на сертификата

Сертификат срок на валидност е интервалът от време, през който подписващият CA гарантира, че ще поддържа информация за състоянието си. Браузърите отхвърлят всякакви сертификати с период на валидност, който завършва преди или започва след датата и часа на проверката за валидиране.

3. Браузърът проверява състоянието на отмяна на сертификата

Когато се издава сертификат, се очаква той да бъде използван през целия му срок на валидност. Разбира се, различни обстоятелства могат да накарат даден сертификат да стане невалиден, преди естествено да изтече.

Такива обстоятелства могат да включват промяна на името на субекта или съмнение за компрометиране на личния им ключ. В случаи като този CA трябва да отмени съответния сертификат и потребителите също така се доверяват на CA, за да уведомят браузърите за състоянието на оттегляне на техните сертификати.

Списъци за анулиране на сертификати (CRL)

Списъците с анулирани сертификати (CRL) се превърнаха в индустриален стандарт за проверка за анулирани сертификати от 2024 г. Сертификатните органи периодично издават подписани, подпечатани с времеви печат списъци с анулирани сертификати, които браузърите могат да изтеглят и кешират локално.

Въпреки че CRL-тата преди това се смятаха за по-малко ефективни от методите за проверка в реално време, индустрията е разпознала значителни предимства, които ги правят предпочитан подход:

• Подобрена поверителностCRL-овете защитават поверителността на потребителите, като елиминират необходимостта от запитвания до външни сървъри за специфични сертификати, което би могло да разкрие модели на сърфиране.
• Оперативна ефективностCA могат да управляват отмяната по-ефективно, без да поддържат високодостъпни услуги за реагиране в реално време.
• Намалени разходи за инфраструктураПремахването на необходимостта от денонощни OCSP реагиращи значително намалява оперативните разходи.
• По-добро кеширанеСъвременните браузъри могат ефективно да кешират и актуализират CRL, минимизирайки проблемите със закъснението, които преди това бяха в полза на методите в реално време.

Към март 2024г. Форумът на CA/Browser изисква всички публично доверени CA да предоставят CRL, като същевременно прави другите методи за отмяна незадължителни.Някои големи сертифициращи органи са преустановили алтернативни услуги за анулиране в полза на подходи, базирани само на CRL.

Протокол за онлайн сертификат (OCSP)

Протоколът за онлайн статус на сертификата (OCSP), описан в RFC 6960, беше проектиран да осигурява проверка за анулиране на сертификати в реално време, като позволява на браузърите да запитват OCSP сървъри (отговори) за конкретни сертификати. Въпреки че OCSP беше широко възприет през 2010-те години като подобрение спрямо периодичните изтегляния на CRL, индустрията до голяма степен се е отказала от този подход.

• OCSP вече е незадължителен за публично доверените CA (в сила от март 2024 г.). Значението на OCSP е... намаляващата; например, Нека да шифроваме премахна OCSP URL адреси през май 2025 г. и спря отговарящите през Август 2025.
• Някои браузъри са деактивирали OCSP проверката или я прилагат по начин, който осигурява минимални ползи за сигурността.

OCSP СшиванеВариант, наречен OCSP Сшиване остава полезен в някои сценарии, където сървърите включват OCSP отговори директно в TLS ръкостискане, като се избягват отделни клиентски запитвания към OCSP отговарящите. Това обаче изисква специфична конфигурация на сървъра. Скобяването се поддържа от повечето сървъри/CDN, но полезността му намалява, тъй като големите CA изтеглят OCSP.

Как това всъщност работи днес в браузърите: От 15 март 2024 г. форумът CA/B изисква публично доверените CA да публикуват CRL, докато OCSP е по избор. Съвременните браузъри обикновено не запитват OCSP или не изтеглят CRL за всеки сайт. Вместо това те използват агрегирани механизми, изградени от публикувани от CA CRL: CRLSets на Chrome и CRLite на Firefox предоставят бързи, запазващи поверителността данни за отмяна на сертификация на клиентите. В резултат на това ролята на OCSP в публичната мрежа намалява; например, Let's Encrypt премахна OCSP URL адреси през май 2025 г. и спря OCSP отговарящите през август 2025 г.

4. Браузърът проверява издателя

Сертификатите обикновено се свързват с две организации:

1. - емитент, което е субектът, който притежава ключа за подписване и
2. - предмет, който се отнася до собственика на публичния ключ, който удостоверява удостоверението.

Клиентите проверяват дали всеки сертификат в пътя е подписан с публичния ключ на предишния сертификат и дали имената на издателя/субекта съвпадат точно по целия път. За допълнителна сигурност, повечето PKI Имплементациите също така проверяват дали ключът на издателя е същият като ключа, с който е подписан текущият сертификат. (Обърнете внимание, че това не е вярно за котвата на доверието, тъй като корените са самоиздадени – т.е. имат един и същ издател и тема.)

Обработка на ограничения

Форматът X.509 v3 позволява на CA да определя ограничения или ограничения за това как всеки сертификат е валидиран и използван като критични разширения. Всеки сертификат в пътя може да наложи допълнителни ограничения, на които трябва да се спазват всички следващи сертификати.

Ограниченията на сертификатите рядко засягат обикновения потребител на Интернет, въпреки че те са доста често срещани в корпоративните SSL решения. Функционалните ограничения могат да служат на няколко оперативни цели, но най-значимото им използване е за смекчаване на известни проблеми със сигурността.

5. Браузърът проверява ограниченията на имената

Частен (но публично доверен) междинен сертификат със съответния ограничения на имената може да предостави на организацията прецизен контрол върху управлението и издаването на сертификати. Сертификатите могат да бъдат ограничени до конкретен домейн или дърво на домейни (т.е. включително поддомейни) за името на домейна на компания или организация. Ограниченията на имената често се използват за междинни сертификати за CA, закупени от публично доверен CA, за да се предотврати издаването от междинния CA на напълно валидни сертификати за домейни на трети страни (напр. google.com).

6. Браузърът проверява ограниченията на политиката

Политиката за сертификати е правен документ, публикуван от СО, официално описва подробно процедурите, които следват за издаване и управление на техните сертификати. CA могат да издадат сертификат по една или повече политики и връзките към тях са включени във всеки издаден сертификат, така че разчитащите се страни могат да оценят тези правила, преди да решат да се доверят на този сертификат.

По правни и оперативни причини сертификатите могат да налагат ограничения върху кои политики могат да бъдат подложени. Ако се установи, че сертификат съдържа критични ограничения на политиката, браузърите трябва да ги валидират, преди да продължат. (Въпреки това в реалния свят рядко се срещат критични ограничения на политиката и затова ще бъдат пренебрегвани в останалата част от тази статия.)

7. Браузърът проверява основните ограничения (известни още като дължина на пътя)

Форматът X.509 v3 позволява на издателите да определят максималната дължина на пътя, която сертификатът може да поддържа. Това осигурява контрол върху това до каква степен всеки сертификат може да бъде поставен в пътя на сертифициране. Това всъщност е важно - през 2009 г. браузърите са пренебрегвали дължината на пътя на сертифициране, докато изследовател не демонстрира представяне, как е използвал сертификата leaf на уебсайта си, за да фалшифицира валиден сертификат за голям уебсайт за електронна търговия.

8. Браузърът проверява използването на ключовете

Разширението „Използване на ключ“ посочва целта на ключа, съдържащ се в сертификата. Примери за такива цели включват шифроване, подписи, подписване на сертификати и т.н. Браузърите отхвърлят сертификати, нарушаващи ограниченията им за използване на ключове, като например да срещнат сертификат на сървър с ключ, предназначен само за подписване на CRL.

9. Браузърът продължава да обработва всички останали критични разширения

След обработка на разширенията, споменати по-горе, браузърите продължават да валидират всички останали разширения, които текущият сертификат определя като критични, преди да преминат към следващото. Ако браузърът достигне сертификат за листа на пътя без грешка, тогава пътят се приема за валиден. Ако се появят някакви грешки, пътят е маркиран като невалиден и не е установена защитена връзка.

Модерно управление на сертификати: по-кратки срокове на валидност и автоматизация

SSL /TLS индустрията претърпя няколко промени през последните години, които коренно промениха начина, по който се издават и управляват сертификатите. Разбирането на тези промени е от решаващо значение за PKI мениджъри, ИТ специалисти и/или всеки друг, който работи с цифрови сертификати.

Съкратени срокове на валидност на сертификатите

През април 2025 г. Форумът на CA/Browser одобри знаково решение (Бюлетин SC-081v3) за драстично намаляване на сроковете на валидност на сертификатите на етапи:

• Текущ (до март 2026 г.)Максимум 398 дни (приблизително 13 месеца)
• Март 15, 2026Максимум 200 дни
• Март 15, 2027Максимум 100 дни
• Март 15, 2029Максимум 47 дни

Промени във валидирането на контрола на домейна (DCV)

Наред с продължителността на живота на сертификатите, периодът за повторна употреба на информация за валидиране на домейни също се свива:

• март 2026: Максимална повторна употреба 200 дни
• март 2027: Максимална повторна употреба 100 дни
• март 2029: Максимална повторна употреба 10 дни

Това означава, че организациите ще трябва да валидират собствеността на домейна много по-често, което прави автоматизацията от съществено значение за практическото управление на сертификатите.

Защо тези промени имат значение

Предимства за сигурност:

• По-краткият живот на сертификатите намалява времето за излагане на риск, когато ключовете са компрометирани.
• По-честото валидиране гарантира, че собствеността на домейна остава актуална
• По-бързо внедряване на подобрения в сигурността в мрежата

Оперативно въздействие:

• Ръчното управление на сертификатите става практически невъзможно
• Организациите трябва да внедрят автоматизирано управление на жизнения цикъл на сертификатите
• Необходими са по-чести процедури за валидиране на домейни

Изисквания за автоматизация

Тези промени правят автоматизацията на сертификатите не само полезна, но и необходима. Организациите трябва сериозно да обмислят:

• Прилагане ACME (Среда за автоматично управление на сертификати) или подобни протоколи
• Разполагане решения за управление на жизнения цикъл на сертификатите
• Подгответе инфраструктурата за чести подновявания и валидации
• Подгответе се за прехода към по-кратки срокове на валидност на сертификатите

Интеграция на прозрачност на сертификатите

Съвременните браузъри все по-често изискват или валидират регистрационни файлове за прозрачност на сертификатите (CT), които предоставят публични, одитираеми записи за всички издадени сертификати. Това помага за откриване на:

• Неправилно издадени сертификати
• Неоторизирано издаване на сертификат
• Проблеми със съответствието с CA

Заключение

Дигиталният пейзаж остава сложна система от взаимосвързани компоненти, а сигурността на браузъра продължава да бъде активна област на развитие, която включва: 

• По-кратък срок на валидност на сертификатитеИндустрията се насочва към 47-дневни срокове на валидност на сертификатите до 2029 г., което прави автоматизацията от съществено значение за практическото управление на сертификатите.
• Промени в метода за анулиранеПреминаването от OCSP обратно към CRL отразява приоритета на индустрията върху поверителността на потребителите и оперативната ефективност.
• По-строг надзор от страна на CAБраузърите станаха по-агресивни по отношение на налагането на съответствие и премахването на доверието от неефективни сертифициращи органи.

Тези промени представляват фундаментална промяна към по-автоматизирано, съобразено с поверителността и сигурността управление на сертификатите. Организациите трябва да започнат да се подготвят сега за по-кратък срок на валидност на сертификатите и автоматизирани процеси на подновяване.

Доверието продължава да играе важна роля за осигуряване на безопасността на потребителите онлайн. Препоръчваме ви да сте информирани за тези развиващи се стандарти и да преглеждате политиките и данните за съответствие на вашия сертифициращ орган. Както показват тези промени, екосистемата от сертификати активно се адаптира, за да подобри сигурността и защитата на поверителността.

За най-актуална информация относно най-добрите практики за управление на сертификати и подхода на SSL.com към тези промени в индустрията, моля, посетете нашия страница за сравнение на сертификати.

Благодарим ви, че избрахте SSL.com, където вярваме, че a по-безопасно Интернет е а по-добре Интернет.