Două certificate CA pot avea aceeași cheie publică și același subject și totuși să nu fie interschimbabile. Unul este auto-semnat, celălalt este semnat încrucișat de rădăcina veche, iar numele emitentului, numerele de serie și semnăturile lor diferă. O frunză se poate lega specific de unul dintre ele prin Authority Key Identifier. Acea legătură rămâne invizibilă până când un client alege lanțul greșit și handshake-ul eșuează fără un motiv evident.

Efectuați aceste cinci verificări în ordine: fiecare exclude o altă defecțiune.

Verificarea 1: desenați ambele lanțuri înainte de a atinge șablonul

Notați căile. Populația veche are încredere în Rădăcina veche A, care a emis CA B, care a emis frunza serverului. Populația nouă are încredere direct în CA B auto-semnată. Ambele certificate B poartă aceeași cheie și același subject, și exact de aceea cine citește o linie de subject vede o CA unde clientul vede două.

Copia semnată încrucișat trebuie să fie și ea un certificat CA real, cu basic constraints și key usage care permit semnarea.

Verificarea 2: comparați câmpurile AKI, nu doar cheia

Numele emitentului frunzei trebuie să corespundă subjectului lui B, iar acea parte de obicei se susține. Authority Key Identifier este locul unde cele două copii diverg, pentru că poate purta un identificator de cheie, un emitent de certificat și un număr de serie. Identificatorul de cheie corespunde ambelor copii, întrucât cheia este identică. Câmpurile emitent și serie corespund exact uneia, și de aceea un lanț construit împotriva copiei auto-semnate poate eșua împotriva celei semnate încrucișat.

Inspectați frunza în loc să ghiciți: openssl x509 -in server.pem -noout -ext authorityKeyIdentifier.

Apoi comparați ambii candidați cu openssl x509 -in b-cross.pem -noout -text | grep -A2 "Authority Key Identifier", și aceeași comandă împotriva copiei auto-semnate.

Dacă frunza poartă emitent și număr de serie, lanțul este completat doar de certificatul pe care aceste valori îl descriu, indiferent de copia pe care clientul a încărcat-o.

Verificarea 3: schimbați politica de emitere, niciodată octeții semnați

Extensiile trăiesc în interiorul semnăturii. Adăugarea, eliminarea sau editarea uneia pe o frunză existentă nu este o reparație, este alt certificat și necesită reemitere. Schimbarea aparține politicii de emitere: authorityKeyIdentifier = keyid,issuer:always face ca frunzele noi să poarte legătura specifică certificatului, în timp ce keyid singur păstrează forma mai laxă potrivită pentru o tranziție deliberată de semnare încrucișată. Decideți pe care o vrea PKI-ul dumneavoastră înainte de semnarea următorului lot.

Editarea unui șablon partajat schimbă și fiecare certificat viitor, nu doar serverul din fața dumneavoastră.

Verificarea 4: verificați fiecare populație de încredere separat

Testați calea veche și calea nouă ca rulări separate. openssl verify -purpose sslserver -verify_hostname vpn.example -CAfile old-root.pem -untrusted b-cross-signed.pem server.pem exersează ruta semnată încrucișat, iar aceeași comandă cu rădăcina nouă și fără fișier untrusted exersează ruta auto-semnată. Amestecarea ambelor rădăcini într-un singur pachet ascunde ce lanț a fost selectat. Repetați apoi cu clienți reali, pentru că un backend VPN poate prefera un lanț sau poate fixa un certificat în moduri pe care openssl nu le face.

Livrați certificatul intermediar prin configurația de serviciu pe care clientul o citește efectiv, nu printr-o pagină wiki.

Verificarea 5: țineți calea veche pe un ceas de retragere

Semnarea încrucișată ține în viață prin proiectare o cale veche de încredere, ceea ce este deopotrivă scopul și riscul. Nu remediază o rădăcină veche compromisă și nu elimină acea rădăcină din niciun client. Notați când calea veche încetează să mai acorde încredere și confirmați că acea zi chiar vine.

Dacă fiecare client poate prelua rădăcina nouă înainte ca frunzele să se miște, o implementare simplă cu încredere dublă este mai simplă decât semnarea încrucișată și lasă un lucru mai puțin de retras.

Articole similare