când controlorii de domeniu reînnoiesc automat certificatele de mai sus, vor ști ei să se uite la CA subordonată pentru reînnoirea/emiterea unui nou certificat pe baza acelor șabloane necesare pentru un controler de domeniu?
da. Clienții de înscriere vor enumera mai întâi toate CA care acceptă șablonul solicitat de la AD. Apoi clientul va alege CA aleatoriu din această listă pentru a trimite cererea de reînnoire. Adică, eliminarea tuturor șabloanelor din CA rădăcină este în regulă, clienții vor încerca un alt CA disponibil care acceptă acest șablon.
p.s.deși aș lua în considerare să convertesc Enterprise Root CA (aderat la domeniu) în Standalone Root CA (membru al grupului de lucru), astfel încât să puteți dezactiva CA root pentru cea mai mare parte a timpului, deoarece nu are nimic de făcut online. L-ați activa o dată sau de două ori pe an pentru a publica CRL sau atunci când trebuie să semnați certificatul CA subordonat. Dar este o altă întrebare, doar o modalitate bună de a urma cele mai bune practici.
Actualizare 1 (21.01.2022)
Paginile Microsoft Docs nu arată nimic despre cum enumera CA-urile etc.
Înscriere client apeluri generice IX509Înscriere::Înscriere care efectuează o serie de apeluri (pași foarte simplificați):
Descoperirea CA folosind [MS-XCEP]
- Încărcați o listă de politici din registru.
- Politici de grup de către PolicyId atribut.
- Grupurile sunt sortate după Cost atribut, apoi de Autentificare atribut. Autentificarea Kerberos are o prioritate mai mare. Grupurile de rest sunt plasate în ordine arbitrară.
- Interogați fiecare politică apelând IPolicy::GetPoliciesResponse metoda web. Răspunsul conține o listă de servicii web CA
- Răspunsul conține: o listă de șabloane de certificat pe care apelantul are permisiunea de a le înscrie și o listă de puncte finale CA (care implementează [MS-WSTEP] protocol) cu informații despre șabloanele de certificat acceptate.
- pregătiți o listă goală.
- pentru fiecare grup de politici sortat:
- comanda CA-uri de Cost atribut, apoi de Autentificare atribut. Autentificarea Kerberos are o prioritate mai mare. Grupurile de rest sunt plasate în ordine arbitrară. Eliminați CA pentru care apelantul nu are permisiuni. Adăugați CA ordonate la listă în aceeași ordine.
- repetați (8) până când toate CA sunt adăugate la listă.
- pentru fiecare CA din lista rămasă:
- generați cererea de certificat și apelați ICertRequest::Submit pentru a trimite cererea CA selectată.
- repetați (11) până când apelul reușește.
Descoperirea CA folosind [MS-WCCE]
- apelul în buclă do-while de ICertConfig::Următorul pentru a enumera toate CA-urile descoperite automat (locale, înregistrate în AD, stocate în directorul partajat etc.). Aceasta va produce o listă cu toate CA posibile.
- Pentru fiecare client CA face un
ICertRequest2::GetCAProperty suna cu CR_PROP_TEMPLATES ca propID parametru. Eliminați CA offline.
- Lista de filtrare obținută în (1) pentru a elimina CA care nu acceptă șablonul solicitat.
- dacă Conștientizarea site-ului CA este configurat, filtrează lista de CA care se află pe același site ADDS ca client. Nu filtrați dacă conștientizarea site-ului CA nu este configurată sau nu există CA în același site ADDS în care locuiește clientul.
- Apel ICertRequest::GetCACertificate pentru a prelua certificatul CA și a valida fiecare. Eliminați CA-urile cu certificat invalid sau nede încredere.
- alegeți CA arbitrară din lista rămasă, generați cererea de certificat și apelați ICertRequest::Submit pentru a trimite cererea CA selectată.
Din nou, este o secvență de activități simplificată pentru clientul de înscriere pentru a descoperi CA și a trimite cererea de certificat.
Actualizare 2
Știți ce efecte vor avea certificatele existente care au fost emise din SubCA existent după ce înlocuim rootCA?
literalmente nimic, atâta timp cât CA root este de încredere de către clienți.
