Лист сертификата важећи, ланац истекао: прочитајте дубину

Грешка због истека може да припада издаваоцу, а не листу. Прочитајте дубину провере и улазе поверења пре него што обновите сертификат који још изгледа актуелан.

Проверавате сертификат сервера, видите да је на сату још месеци, а клијент ипак одбија везу са поруком о истеку. Датум који читате припада листу, а жалба може бити о нечему дубљем у путањи. Провера пролази кроз ланац, и сваки сертификат који овај пролаз изабере може да не успе у сопственом прозору важности. Прочитајте који није успео пре него што било шта обновите.

Дубина именује сертификат који није успео

У OpenSSL дијагностици, дубина 0 је циљни сертификат, а дубина 1 је издавалац који га је потписао, при чему већи бројеви настављају ка сидру поверења. Истек пријављен на дубини 1 не противречи актуелном notAfter на листу, па поновна провера видљивог сертификата никада неће објаснити грешку.

Запишите отисак неуспелог сертификата заједно са његовим subject, јер различити сертификати могу да носе исто име CA. Укрштено потписивање ствара управо ту ситуацију: исти орган се појављује више од једном, са различитим датумима важности, и проверавач је изабрао онај који нисте очекивали. Позната ознака није идентификатор, а отисак је оно што разликује два објекта која деле име.

Обратите пажњу и на производе са више од једне улоге сертификата. На OpenVPN Access Server, сертификати који штите веб интерфејсе одвојени су од оних који се користе за VPN везе, па прегледач који отвори администраторску страницу ништа не доказује о путањи тунела.

Улази поверења нису исто што и кандидати за ланац

Дајте проверавачу два улаза одвојено и експлицитно. Датотека поверења држи сидра која прихватате; непоуздан пакет држи посредне сертификате понуђене за изградњу путање. Њихово мешање је начин на који људи случајно уздигну посредни сертификат у корен и затим се питају зашто их иста грешка прати између машина.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

Искључивање подразумеване путање и складишта са -no-CApath -no-CAstore одржава тест поштеним: резултат тада зависи од датотека које сте навели, а не од онога чему се радна станица случајно поверава. OpenSSL референца за проверу документује ове опције и дијагностику коју производе.

-show_chain исписује изграђени ланац када провера успе, што је корисно за потврду да је путања она коју сте намерили. Када не успе, задржите пријављену дубину и subject; та два поља говоре следећем читаоцу који сертификат да прегледа.

Оно што ово не ради је да репродукује политику сваког клијента. Pin, ограничење намене или провера идентитета специфична за клијента живи у клијенту, а не у овој команди. То су подешавања која треба прегледати када провера на серверу прође, а веза и даље не успева. Држите две дијагнозе одвојено, иначе ћете обновити здрав сертификат док јурите грешку pinning-а.

Шта провера доказује и шта изоставља

Ово је провера путање и намене према датотеци поверења коју сте доставили. За проверу имена преко HTTPS, додајте очекивано име домаћина кроз одговарајућу опцију; за VPN везу, задржите конфигурисане провере идентитета клијента и користите материјал поверења који тај клијент заиста чита.

Оно што сервер шаље је скуп кандидата, а не путања коју ће ваш клијент на крају изградити. Локално поверење и правила изградње библиотеке обликују резултат, зато исти одговор може да се провери на једној машини и не успе на другој. Упоредите одржавано складиште поверења и TLS имплементацију неуспелог клијента са онима клијента који ради пре него што претпоставите идентичну процену. Разлика тамо објашњава многе извештаје „само овај лаптоп не успева“.

Да видите прозор сваког сертификата уместо један по један, испишите их као скуп:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

Та друга команда наводи subject-е и издаваоце без ручног декодирања сваке датотеке, тако примећујете посредни сертификат чији је датум прошао док лист још изгледа добро.

Поправите путању без слабљења провере

Када се доставља истекао посредни или застарео укрштено потписан сертификат, набавите тренутно подржани ланац издаваоца и распоредите га кроз документовани ток сертификата услуге. Када клијенту недостаје намењено одржавано сидро, ажурирајте његову управљану конфигурацију поверења или клијентски софтвер. Одуприте се пречици да сваки сертификат у пакету означите као корен само да утишате поруку.

Руковање кореном заслужује напомену, јер резимеи га често преувеличавају. RFC 5280 третира сидро као улаз који стоји изван предвиђене путање, док OpenSSL документује провере важности које укључују његов коренски CA сертификат. Обе тврдње су тачне за њихове системе; уопштавање понашања истека корена једне библиотеке на сваког клијента даје самоуверене нетачне одговоре.

Након промене, присилите нову аутентификацију на погођеном клијенту и потврдите да је конкретна порука о истеку нестала. Обновите лист само ако је сам лист неодговарајући. Искључивање провера времена или враћање историјског укрштеног сертификата не ствара важећу тренутну путању; само одлаже следећи неуспех.

Повезани чланци