Notă: înainte de a face orice modificări descrise în această postare, asigurați-vă că efectuați o copie de rezervă.
Majoritatea administratorilor se adresează foarte simplu atunci când instalează rolul Serviciului de certificare al serviciilor Active Directory (AD CS) Următorul -> Următor ->. -> PROFIT. Pe de o parte este bine, dar de multe ori nu este foarte bun. Odată ce este bine - va funcționa. Din nefericire - la apariția unor condiții specifice (de exemplu, clienții externi ai lemnului actual) începe să funcționeze mai rău și chiar încetează să mai fie eficient. Astăzi intenționez să iau în considerare aceste probleme, în calitate de clienți non-permanenți (care nu suportă LDAP) și clienți externi, în special acest scenariu destul de comun.
Prima recomandare este că nu trebuie să instalați IIS pe serverul CA (dacă nu aveți un singur server în rețea). La instalarea rolului AD CS, expertul sugerează instalarea IIS pentru legăturile HTTP la fișierele CRT și CRL. Cred că dacă aveți un server web intern și / sau extern, instalați încă un server pe serverul CA - este o idee proastă. Prin aceasta pur și simplu vă adăugați munca suplimentară și nu rezolvați unele probleme. Instalarea noului rol mărește suprafața de atac pentru atacatori, ia administratorii de timp, crește costul de IIS pentru a proteja organizația și nu abordează problema de a servi clienții externi ca publicarea serverului CA la Internet (deși IIS doar rol. Pe un rol atac de succes, puteți obține controlul asupra întregului serverul ) ideea este atât de proastă și de nereușită încât nu există dorința de ao lua în considerare. În general, cred că pe serverul CA, în plus față de rolul CA, nu ar trebui să existe nimic. Prin urmare, atunci când instalați rolul CA destituit cu înțelepciune. În schimb, vom folosi un server web dedicat, cel mai probabil instalat în compania dvs. În același timp, poate rula sub orice sistem de operare, cel puțin linux. Acest lucru va fi scris chiar mai jos.
Am examinat deja problemele generale într-una din posturile anterioare: Punctele de distribuire a CRL și accesul la informații despre autoritate. Din motivele descrise în această postare, ne încadrăm toate legăturile la LDAP.
- Pașii necesari pentru cazurile de instalare proaspătă a rolului CA care a avut loc înainte de eliberarea primului certificat.
Cu acest pas, vom anula utilizarea referințelor LDAP, care poate fi destul de util pentru un număr de tipuri de clienti, cum ar fi clienții de telefonie mobilă, clienții de pe Internet, clienții grupuri de lucru și alte păduri, etc. Și, de asemenea, a șters legăturile HTTP implicite care indică spre serverul CA.
- Pași necesari pentru cazurile în care serverul CA a emis deja certificate.
Pentru aceasta, rulați modulul snap-in CertSrv.msc, selectați proprietățile CA și faceți clic pe fila Extensii. În această filă, selectați linkul care începe cu LDAP: //. Ștergeți toate semnele de selectare, cu excepția publicării CRL-urilor în această locație și a CRL-urilor pentru publicarea Deltei în această locație (dacă intenționați să utilizați CRL-ul Delta). De asemenea, ștergeți legăturile HTTP care indică spre serverul CA în sine. Salvați modificările și reporniți Serviciile de certificate.
Cu acest pas, am dezactivat publicarea referințelor LDAP și HTTP în certificatele nou emise. Cu toate acestea, avem deja o infrastructură PKI de lucru, prin urmare, certificatele emise anterior conțin legături către LDAP. Pentru a asigura funcționalitatea acestora, vom continua să publicăm fișiere CRT / CRL în LDAP.
O mică groapă. Cred că mulți au observat cum sunt numiți fișierele. De exemplu, CRT-ul implicit are un nume cu următorul format:
Același lucru se va aplica LCR. În conformitate cu punctul 3.2.5.1.6 din specificația protocolului [MS-CSRA]:
1.When această metodă este invocată, CA trebuie să creeze o nouă bază și / sau CRL delta pentru fiecare cheie CA, așa cum se specifică în pașii următori 2, 3, 4, 5, 6 și 7. Tipul de CRL pentru a crea (baza, delta sau ambele) pentru fiecare cheie CA se determină după cum urmează:<38>
CA ar trebui să creeze un nou CRL de bază pentru fiecare cheie CA.
În cazul în care CA a permis Delta CRLs, așa cum este indicat printr-o valoare Config_Delta_CRL_Validity_Period nenul, CA trebuie să creeze un nou delta CRL în plus față de o nouă CRL de bază, pentru fiecare cheie CA.
În cazul în care delta CRL-urile sunt dezactivate (Config_Delta_CRL_Validity_Period este 0) și au fost activate anterior (Previous_Delta_CRL_Validity_Period nu este egal cu zero), AC trebuie să creeze un nou delta CRL în plus față de un nou CRL de bază pentru fiecare cheie CA.
Pe serverul web, creați un dosar cu un nume arbitrar (de exemplu, cu numele pki), în care vor fi stocate fișierele noastre. Distribuiți acest dosar și adăugați permisiunile de scriere pentru acesta pentru contul computerului pe care rulează serverul CA. Cu toate acestea, rețineți că drepturile trebuie editate atât la nivelul drepturilor NTFS, cât și al drepturilor de distribuire. În principiu, drepturile de creare de fișiere / date de scriere sunt destul de suficiente pentru această sarcină. În IIS, într-un site Web arbitrar, creați un director virtual și specificați folderul în care sunt stocate fișierele CRT / CRL ca cale.
Deoarece vom publica fișierele pe un server web dedicat, trebuie să editați extensiile în consecință. Executați modul snap-in CertSrv.msc, selectați proprietățile CA și faceți clic pe fila Extensii. Faceți clic pe butonul Adăugați și în câmpul Locație specificați calea vizualizării:
Am alocat componenta necesară a numelui fișierului CRL. Restul este pe gustul tău. Și setați casetele de selectare pentru publicarea LCR-urilor în această locație și CRL-urile pentru publicarea Deltei în această locație (dacă intenționați să utilizați CRL Delta). Dacă Delta CRL nu este utilizată pe serverul CA,
Acum trebuie să adăugați un link care va fi publicat în certificatele emise. Pentru a face acest lucru, adăugați o nouă legătură HTTP care va indica spre serverul web, de exemplu:
Și bifați caseta: includeți în extensiile CDP certificatelor emise și includeți în CRLS. Clienții folosesc acest lucru pentru a găsi locațiile CRL Delta (dacă se utilizează Delta CRL).
Același lucru este făcut pentru extensia AIA pentru a obține un link ca acesta:
Și bifați caseta de lângă Includeți în extensia AIA a certificatelor emise. După cum am spus, nu este posibilă publicarea automată a CRT în locații non-standard, deci va trebui să le redenumiți manual.
Notă: numele fișierelor fizice trebuie să fie identice cu numele din referința HTTP.
În principiu, în cele din urmă ar trebui să obțineți acest tip de link-uri și semne de verificare instalate:
CDP - instalare nouă
C: \ WINDOWS \ system32 \ CertSrv \ CertEnroll \
Publicați LCR-uri în această locație
Publicați CRL Delta în această locație
fișier: // \\ WebServerName \ pki \ Company_RCA
Publicați LCR-uri în această locație
Publicați CRL Delta în această locație
CDP - Instalare moștenită
C: \ WINDOWS \ system32 \ CertSrv \ CertEnroll \
Publicați LCR-uri în această locație
Publicați CRL Delta în această locație
Notă: Nu ștergeți această cale deoarece este utilizată de serverul CA în sine.
fișier: // \\ WebServerName \ pki \ Company_RCA
Publicați LCR-uri în această locație
Publicați CRL Delta în această locație
ldap: /// CN =
Publicați LCR-uri în această locație
Publicați CRL Delta în această locație
AIA - instalații noi și vechi
C: \ WINDOWS \ system32 \ CertSrv \ CertEnroll \
nicio casetă de selectare. Rămâne neschimbată.
Nu vă îndemn să vă grăbiți imediat și să remodelați totul. Aceste recomandări sunt doar pentru înțelegerea naturii problemei și a modului în care aceasta poate fi rezolvată. Cu ajutorul lor, dacă este necesar, puteți pregăti în mod independent un plan pentru modificarea extensiilor CDP și AIA.
Trimiteți-le prietenilor: