Инфраструктурата за публичен ключ (PKI) е криптографска система, която осигурява автентикация, криптиране и управление на цифрови сертификати в уеб приложения. Имплементирането на PKI в уеб приложение означава изграждане на механизъм, при който всяка страна доказва самоличността си чрез сертификат, издаден от доверен удостоверителен орган (CA). Правилната архитектура делегира проверката на сертификати към gateway или edge компонент, а приложението получава вече валидирани резултати. Това разграничение е ключово: то намалява сложността в приложната логика и централизира сигурността на едно място.

Каква е оптималната архитектура за имплементиране на PKI в уеб приложения?

Централизираната проверка на сертификати на gateway ниво е архитектурният избор с най-висока инженерна стойност. Gateway компонентът действа като единна точка на вход и извършва първичната валидация на клиентския сертификат, преди заявката да достигне до приложението. Отделен сервис обработва OCSP и CRL заявките за статус проверка, прилагайки централизирани правила за доверие. Приложението получава само резултата от тази проверка, без да пренаписва PKI логика.

Тази архитектура носи конкретни предимства:

• Единна точка на валидация: Gateway прилага еднакви правила за всички входящи заявки, без риск от несъответствие между отделни сервизи.
• Отделен статус сервис: OCSP и CRL се управляват централизирано, което опростява одитите и реакцията при инциденти.
• Без дублиране на логика: Приложението не имплементира PKI проверки самостоятелно, а разчита на вече верифицирани данни от gateway.
• По-лесна поддръжка: Промяна в политиките за доверие се прилага на едно място, а не в десетки микросервизи.

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

Професионален съвет: Никога не поставяйте OCSP проверката директно в критичния път на всяка HTTP заявка. Използвайте кеширане с TTL, съобразен с политиката на CA, за да избегнете латентност при висок трафик.

Как се интегрира mTLS в уеб приложения?

Взаимната TLS автентикация (mTLS) се въвежда на транспортния слой, а не в самото приложение. Уеб сървърът или reverse proxy компонентът валидира клиентския сертификат по време на TLS handshake и предава резултатите нагоре към приложението. Приложението не вижда суровия TLS трафик, а получава структурирана информация за идентичността на клиента.

Правилната интеграция следва тези стъпки:

1. Конфигурация на reverse proxy: Nginx, Apache или Envoy се конфигурират да изискват клиентски сертификат (ssl_verify_client on в Nginx). Proxy валидира сертификата спрямо доверения CA bundle.
2. Предаване на сертификатни данни: SSL_CLIENT_CERT и SSL_CLIENT_VERIFY се предават като HTTP хедъри към приложението. SSL_CLIENT_VERIFY съдържа резултата от валидацията (SUCCESS, FAILED, NONE).
3. Обработка в приложението: Приложението чете хедърите и извлича атрибутите на сертификата (CN, OU, SAN) за авторизация. Библиотеки като mtls-bundle за Symfony автоматизират тази обработка.
4. Разграничение транспорт/приложение: Транспортният слой проверява криптографската валидност. Приложният слой прилага бизнес правилата за достъп въз основа на идентичността.
5. Тестване преди продукция: Генерирайте тестови CA и клиентски сертификати, верифицирайте всички хедъри и симулирайте ревокиран сертификат преди пускане в продукция.

Разграничението между транспортен и приложен слой е критично. Приложението трябва да използва вече валидирани резултати от TLS handshake, за да избегне дублиране и несъответствия. Ако приложението се опита да валидира сертификата самостоятелно, рискува да работи с различни правила от тези на proxy.

Професионален съвет: В zero-trust архитектури mTLS не служи само за криптиране, а като постоянен слой за идентификация при всяка заявка. Конфигурирайте proxy да отхвърля заявки без валиден клиентски сертификат на мрежово ниво, преди да достигнат до приложението.

Как да управляваме жизнения цикъл на сертификати?

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

PKI платформи с REST API и уеб интерфейс решават този проблем. pkisquire е пример за такава платформа с отворен код, която осигурява:

• Издаване на RSA и ECC ключове с поддръжка на CSR submission през уеб интерфейс и API.
• Ревокация с CRL и валидиране на статус чрез OCSP в реално време.
• Автоматизация на enrollment чрез протоколите SCEP и EST, което позволява устройствата и сервизите да получават сертификати автоматично.
• Централизирано управление на CA йерархии с персонализирани профили и политики.

 

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

Публична срещу частна PKI: кога коя да изберем?

Изборът между публична и частна PKI определя модела на доверие и нивото на контрол върху сертификатните политики.

Частната PKI позволява на организациите да контролират собствени CA йерархии и сертификатни политики, независимо от публичните коренни хранилища на браузърите. Частният CA сертифицира вътрешни системи без публична регистрация и поддържа персонализирани профили. Това е правилният избор за корпоративни интранет системи, B2B API интеграции и IoT устройства.

Публичната PKI е задължителна, когато крайните потребители достъпват приложението през браузър без предварителна конфигурация. Let’s Encrypt предоставя безплатни публични сертификати с автоматично обновяване чрез ACME протокол. За смесени сценарии, при които приложението обслужва едновременно публични потребители и вътрешни системи, се използват двуслойни архитектури с различни CA за всеки тип трафик.

Какви са честите грешки при имплементиране на PKI?

Грешките при PKI имплементация обикновено не се проявяват веднага. Те се появяват при ротация на сертификати, смяна на CA или промяна в конфигурацията на load balancer.

Най-честите проблеми са:

• Load balancer не предава клиентски сертификат: L7 proxy компоненти могат да терминират TLS и да не препредадат SSL_CLIENT_CERT към приложния слой. Резултатът е, че приложението работи с непълна информация за потребителя.
• Несъответствие между транспортен и приложен слой: Proxy валидира сертификата по едни правила, а приложението прилага различни. Това създава пропуски в сигурността.
• Нестабилен мапинг на идентичност: Атрибутите CN, OU и SAN трябва да са стабилни и консистентни. Промяна в сертификатния профил при ревокация и преиздаване може да наруши правата на достъп.
• Липса на централизирана OCSP/CRL проверка: Без централизирана услуга за статус, отзованите сертификати продължават да работят до следващото рестартиране на приложението.

Ефективната имплементация на сертификатна автентикация в API изисква пет ключови елемента: издаване на сертификати, доверие в CA, изискване на mTLS, мапинг на сертификатната идентичност и тестове преди продукция.

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

Основни изводи

Успешното имплементиране на PKI в уеб приложение изисква централизирана проверка на сертификати на gateway ниво, правилна интеграция на mTLS и автоматизиран lifecycle мениджмънт.

 

Какво научих от реални PKI имплементации

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

Правилният подход е обратен: приложението трябва да е максимално невежо за PKI детайлите. То получава хедър с резултата от валидацията и атрибутите на сертификата. Всичко останало е работа на gateway и статус сервиза. Когато следвате този принцип, смяната на CA или промяната в политиките не изисква промяна в приложния код.

Второто нещо, което подценяват повечето екипи, е lifecycle автоматизацията. Ръчното управление на сертификати работи при пет сертификата. При петдесет вече е риск. При петстотин е катастрофа в очакване. Инвестицията в PKI платформа с автоматизирано издаване и мониторинг се изплаща при първия предотвратен инцидент с изтекъл сертификат в продукция.

Накрая: тествайте ревокацията. Не само успешната автентикация. Симулирайте ревокиран сертификат, изтекъл сертификат и липсващ хедър от proxy. Тези три сценария покриват деветдесет процента от реалните инциденти.

— smartmanagement.bg

Решения за PKI сигурност от Smartmanagement

Smartmanagement предлага решения за сигурност на уеб приложения, включително физически ключове YubiKey, които работят в комбинация с PKI инфраструктура за многофакторна автентикация. YubiKey поддържа PIV стандарта, което го прави директно съвместим с PKI за уеб приложения: сертификатът се съхранява на физическия ключ, а автентикацията изисква физическо присъствие.

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

Често задавани въпроси

Какво е PKI в контекста на уеб приложения?

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

Каква е разликата между TLS и mTLS?

При стандартен TLS само сървърът представя сертификат пред клиента. При mTLS (взаимен TLS) и двете страни представят сертификати, което осигурява двупосочна автентикация на транспортния слой.

Трябва ли приложението да валидира сертификата самостоятелно?

Не. Приложението трябва да получава вече валидирани резултати от gateway или reverse proxy чрез HTTP хедъри като SSL_CLIENT_VERIFY. Самостоятелната валидация в приложението дублира логика и създава риск от несъответствия.

Кога да изберем частна PKI вместо публична?

Частната PKI е правилният избор за вътрешни корпоративни системи, B2B API интеграции и IoT устройства, при които организацията контролира всички клиенти. Публичната PKI е задължителна за приложения, достъпвани от крайни потребители през браузър без предварителна конфигурация.

Как да автоматизираме ротацията на сертификати?

Използвайте PKI платформа с поддръжка на SCEP или EST протоколи за автоматичен enrollment и ротация. Платформи като pkisquire предоставят REST API, който позволява автоматизирано издаване и ревокация без ръчна намеса.

Препоръчани

• защо Yubico
  
• YubiKey 5 серия
• YubiKey 5 серия FIPS
• YubiKey Био серия
• YubiHSM 2