Listový certifikát platný, reťaz vypršal: čítajte hĺbku

Chyba vypršania môže patriť vydavateľovi, nie listu. Prečítajte si hĺbku overenia a vstupy dôvery, než obnovíte certifikát, ktorý stále vyzerá aktuálne.

Skontrolujete certifikát servera, vidíte, že na hodinách zostávajú mesiace, a klient napriek tomu odmietne spojenie s hlásením o vypršaní. Dátum, ktorý čítate, patrí listu a sťažnosť sa môže týkať niečoho hlbšie v ceste. Overenie prechádza reťazec a ktorýkoľvek certifikát, ktorý tento prechod vyberie, môže zlyhať vo vlastnom okne platnosti. Prečítajte si, ktorý zlyhal, skôr než čokoľvek obnovíte.

Hĺbka pomenúva certifikát, ktorý zlyhal

V diagnostike OpenSSL je hĺbka 0 cieľový certifikát a hĺbka 1 vydavateľ, ktorý ho podpísal, pričom vyššie čísla pokračujú k ukotveniu dôvery. Vypršanie hlásené v hĺbke 1 nie je v rozpore s aktuálnym notAfter na liste, takže opätovná kontrola viditeľného certifikátu chybu nikdy nevysvetlí.

Zaznamenajte odtlačok zlyhaného certifikátu spolu s jeho subject, pretože rôzne certifikáty môžu niesť rovnaký názov CA. Krížové podpisovanie vytvára presne túto situáciu: tá istá autorita sa objavuje viackrát, s rôznymi dátumami platnosti, a overovateľ vybral tú, ktorú ste neočakávali. Známy štítok nie je identifikátor a odtlačok je to, čo odlišuje dva objekty s rovnakým menom.

Všímajte si aj produkty s viac ako jednou rolou certifikátu. V OpenVPN Access Server sú certifikáty chrániace webové rozhrania oddelené od tých, ktoré sa používajú pre VPN pripojenia, takže prehliadač, ktorý otvorí administrátorskú stránku, nič nedokazuje o ceste tunela.

Vstupy dôvery nie sú to isté ako kandidáti reťazca

Dajte overovateľovi oba vstupy oddelene a výslovne. Súbor dôvery obsahuje ukotvenia, ktoré prijímate; nedôveryhodný balík obsahuje medziľahlé certifikáty ponúkané na zostavenie cesty. Ich miešanie je spôsob, akým ľudia omylom povýšia medziľahlý certifikát na koreň a potom sa čudujú, prečo ich tá istá chyba nasleduje medzi počítačmi.

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

Vypnutie predvolenej cesty a úložiska pomocou -no-CApath -no-CAstore udržiava test poctivý: výsledok potom závisí od súborov, ktoré ste uviedli, nie od toho, čomu pracovná stanica náhodou dôveruje. Referenčná príručka overovania OpenSSL dokumentuje tieto voľby a diagnostiku, ktorú vytvárajú.

-show_chain vypíše zostavený reťazec, keď overenie uspeje, čo je užitočné na potvrdenie, že cesta je tá zamýšľaná. Keď zlyhá, ponechajte hlásenú hĺbku a subject; tieto dve polia povedia ďalšiemu čitateľovi, ktorý certifikát skontrolovať.

Čo to nerobí, je reprodukcia politiky každého klienta. Pin, obmedzenie účelu alebo kontrola identity špecifická pre klienta žije v klientovi, nie v tomto príkaze. To sú nastavenia na kontrolu, keď overenie na serveri prejde a spojenie stále zlyháva. Držte obe diagnózy oddelene, inak obnovíte zdravý certifikát pri prenasledovaní chyby pinningu.

Čo kontrola dokazuje a čo vynecháva

Toto je kontrola cesty a účelu voči súboru dôvery, ktorý ste poskytli. Pre kontrolu názvu HTTPS pridajte očakávané meno hostiteľa príslušnou voľbou; pre VPN pripojenie ponechajte nakonfigurované kontroly identity klienta a použite materiál dôvery, ktorý tento klient skutočne číta.

To, čo server posiela, je množina kandidátov, nie cesta, ktorú váš klient nakoniec zostaví. Lokálna dôvera a pravidlá zostavovania knižnice utvárajú výsledok, a preto sa tá istá odpoveď môže overiť na jednom počítači a zlyhať na inom. Porovnajte udržiavané úložisko dôvery a implementáciu TLS zlyhávajúceho klienta s tými funkčného klienta, než predpokladáte totožné vyhodnotenie. Rozdiel tam vysvetľuje mnohé hlásenia „zlyháva len tento notebook“.

Ak chcete vidieť okno každého certifikátu namiesto jedného po druhom, vypíšte ich ako množinu:

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

Druhý príkaz vypisuje subjecty a vydavateľov bez ručného dekódovania každého súboru, takže odhalíte medziľahlý certifikát, ktorého dátum už uplynul, kým list stále vyzerá dobre.

Opravte cestu bez oslabenia overenia

Keď sa dodáva vypršaný medziľahlý alebo zastaraný krížovo podpísaný certifikát, získajte aktuálne podporovaný reťazec vydavateľa a nasaďte ho dokumentovaným pracovným postupom certifikátov služby. Keď klientovi chýba zamýšľané udržiavané ukotvenie, aktualizujte jeho spravovanú konfiguráciu dôvery alebo klientsky softvér. Odolajte skratke označiť každý certifikát v balíku ako koreň len preto, aby ste správu umlčali.

Zaobchádzanie s koreňom si zaslúži poznámku, pretože zhrnutia ho často preháňajú. RFC 5280 považuje ukotvenie za vstup, ktorý stojí mimo predpokladanej cesty, zatiaľ čo OpenSSL dokumentuje kontroly platnosti, ktoré zahŕňajú jeho koreňový certifikát CA. Obe tvrdenia platia pre ich vlastné systémy; zovšeobecnenie správania vypršania koreňa jednej knižnice na každého klienta dáva sebavedomo nesprávne odpovede.

Po zmene vynúťte na postihnutom klientovi novú autentizáciu a potvrďte, že konkrétna správa o vypršaní zmizla. Obnovte list len vtedy, ak je samotný list nevhodný. Vypnutie časových kontrol alebo obnovenie historického krížového certifikátu nevytvára platnú aktuálnu cestu; len odkladá ďalšie zlyhanie.

Súvisiace články