Puncte:0

Expirarea certificatului rădăcină al serviciilor de backend

drapel ru

Utilizăm mTLS pentru autentificarea serviciilor noastre de backend, iar certificatul rădăcină este setat să expire în 2022. Iată detaliile de expirare pentru toate certificatele:

  • The rădăcină certificatul va expira în 2022
  • The intermediar certificatele vor expira în 2031
  • The frunze certificatele vor expira în 2023

Nu știu de ce certificatul rădăcină a fost setat să expire înainte de toate celelalte și aș dori să evit actualizarea tuturor certificatelor în câteva luni dacă este posibil. Pe baza testelor noastre, totul va funcționa în continuare după expirarea certificatului rădăcină, atâta timp cât certificatele intermediare și cele de frunză sunt încă valabile. Am făcut următoarele teste pentru a valida:

  • Am actualizat certificatele într-un mediu de testare și am setat certificatul rădăcină să expire într-o oră
  • Totul mergea normal după o oră
  • Am mai făcut un test cu certificatele intermediare, făcându-le să expire într-o oră
  • După o oră am început să primim erori de autentificare

Ar putea cineva să confirme dacă testele noastre sunt suficiente pentru a valida că expirarea certificatului rădăcină nu ar trebui să cauzeze probleme?

Vă mulțumim pentru orice informație pe care o puteți oferi!

### Informatii suplimentare ###

Utilizăm autentificare mTLS între serviciile noastre interne:

  • Hashicorp Consul, Nomad și Seif
  • MongoDB
  • Alte câteva servicii

În aceste cazuri, putem găsi certificatele intermediare și de frunză, dar nu și rădăcina.

Daca validez certificatul intermediar, vad ca expira in 1 an desi certificatul root a expirat deja.

Am testat aceste certificate folosind Terraform pentru a crea 3 servere Consul într-un mediu nou. Certificatele de testare au fost instalate pe fiecare instanță și expirarea certificatului rădăcină nu provoacă probleme

drapel br
Este puțin probabil să fi testat suficient acest lucru. Cu siguranță nu aș continua fără multe teste suplimentare. Cu toate acestea, întrebarea ta este destul de vagă și nu oferă prea multe. Ce teste ai facut mai exact? Care este partea de bază în acest scenariu? V-ați amintit să instalați noul CA rădăcină, de scurtă durată, ca ancoră de încredere în partea de baza înainte de testare?
StefB avatar
drapel ru
@garethTheRed Vă mulțumim pentru contribuție. Am mai adăugat câteva detalii la sfârșitul descrierii. În ceea ce privește expirarea certificatului rădăcină, care nu provoacă probleme, s-ar putea să se datoreze faptului că se presupune că certificatul rădăcină *ar trebui* să expire înaintea celui intermediar și să plece? De asemenea, dacă înțeleg bine, în cel mai rău caz aș putea genera un nou certificat rădăcină folosind aceeași cheie privată, iar intermediarul și frunzele ar funcționa în continuare până la propria expirare, corect?
drapel br
Da, dacă utilizați aceeași cheie _și_ exact același subiect, puteți înlocui certificatul rădăcină expirat cu acesta nou. Aceasta este probabil cea mai sigură opțiune. Spui că validezi, dar nu explici cum. Ce instrument folosești pentru a valida? Vedeți, de asemenea, @dave_thompson_085 [commentarii de mai jos](https://serverfault.com/questions/1083180/backend-services-root-certificate-expiration?noredirect=1#comment1414293_1083221).
StefB avatar
drapel ru
Pentru a testa, am implementat un cluster de 3 instanțe Consul care folosesc mTLS pentru a comunica. După cum am spus anterior, nu văd nicio eroare dacă fac ca certificatul rădăcină să expire, dar dacă fac ca certificatul intermediar să expire, primesc erori imediat. Nu cred că certificatul rădăcină este folosit deloc în acel scenariu și va trebui să validez toate celelalte servicii interne. Voi plănui să actualizez certificatul nostru rădăcină pentru a mă asigura că nu ne vom confrunta cu probleme când rădăcina actuală va expira. Multumesc pentru ajutor!
Puncte:0
drapel cn

Funcția de validare a certificatelor compatibile cu RFC 5280 necesită ca toate certificatele din lanț (inclusiv certificatul rădăcină) TREBUIE să se afle în perioadele lor de valabilitate la momentul validării. Adică, funcția corespunzătoare de validare a certificatelor nu va valida lanțul de certificate după ce rădăcina expiră (în 2022).

RFC 5280 §6.1.3.a.3:

Perioada de valabilitate a certificatului include ora curentă.

iar acest lucru se aplică fiecărui certificat din lanț. Dacă descoperiți că certificatul de frunză este validat cu succes față de rădăcina expirată, atunci fie:

  1. există un certificat încrucișat care vă redirecționează către o altă rădăcină
  2. funcția de validare a certificatului este configurată greșit și ignoră anumite erori de validare.
dave_thompson_085 avatar
drapel jp
5280 nu o cere; 6.1.3 se aplică „certificatului i pentru i în 1..n” așa cum este definit în 6.1, care EXCLUDE ancora de încredere (adică rădăcină) -- care nu trebuie să fie deloc un certificat și poate să nu aibă o perioadă de valabilitate.Notă (b) de la pagina 73 și, mai explicit, al doilea paragraf de la pagina 73. **Majoritatea** implementărilor folosesc certificate pentru ancore, iar TTBOMK verifică validitatea, dar o excepție notabilă este aceea că LetsEncrypt continuă să utilizați o cale opțională către rădăcina DST X3, care a expirat pe 30 septembrie, deoarece telefoanele Android vechi neactualizate încă au încredere în ea, dar _nu_ au încredere în rădăcina (mai nouă) ISRG X1.
drapel cn
Să criptăm, le-am rezolvat problema folosind certificate încrucișate. În caz contrar, web-ul ar fi rupt. Aceasta înseamnă că cel puțin o rădăcină neexpirată trebuie să fie prezentă în toate lanțurile posibile.
dave_thompson_085 avatar
drapel jp
Cu siguranță nu este necesar ca toate lanțurile să fie valabile; ITYM trebuie să existe _un_ lanț la o rădăcină neexpirată. Dar acest lucru nu este valabil pentru Android, așa cum este explicat la https://letsencrypt.org/2020/12/21/extending-android-compatibility.html . (De fapt, nu este adevărat pentru Java în general, dar spre deosebire de Android încorporat pe dispozitive de către furnizorii care renunță la suport, Java pe sistemele computerizate poate fi de obicei actualizat și nu are nevoie de acest hack.)

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.