În acest articol voi discuta următoarele subiecte despre complexitatea și cele mai bune practici pentru implementarea PKI de la Microsoft - Active Directory Certificate Services:
Opiniile generale ale PKI
Cu cât este mai integrată, complexă și mai sigură obtinerea infrastructurii în Windows Server, cu atât mai mult este necesar, în plus față de tradițional Active Directory pe un PKI (Public Key Infrastructure, tradus ca infrastructura de chei publice) pentru a asigura încrederea și autentificarea între calculatoare, utilizatori și servicii. Active Directory Certificate Services este o implementare Microsoft PKI care constă din următoarele elemente:
- Autoritatea de Certificare (CA), rădăcină și subordonată
- relații de încredere universală în CA
- certificate emise de CA pentru computere, utilizatori și servicii
- diferite servicii de asistență PKI
- listele de revocare a certificatelor (CRL)
- Responder online (Online Responder, alternativă mai progresivă la CRL)
- Înscriere pe Web (mijloace de solicitare a certificatelor prin intermediul web-ului)
Cerere de certificat automat
Instalarea manuală a certificatului de root CA
Dacă încrederea în CA rădăcină este configurată automat într-un mediu Active Directory și în rețeaua locală, trebuie să instalați un certificat CA în Autoritățile de certificare a principalelor certificate de încredere pentru a avea încredere în CA de la computerele de domeniu la distanță. În caz contrar, fie vor fi emise avertismente cu privire la potențialul pericol al unui certificat semnat de o persoană necunoscută, fie în legătură cu un astfel de server vor fi respinse, cum ar fi, de exemplu, în cazul serviciului Remote Desktop Services Gateway, se va produce următoarea eroare:
Computerul nu poate verifica ID-ul gateway-ului desktop la distanță "server.argon.com.ru". Conectarea la servere fără certificate nu este sigură. Acest computer nu poate verifica identitatea RD "server.argon.com.ru". Nu este sigur să vă conectați la servere. Acest certificat nu a putut fi verificat prin urmărirea acestuia către o autoritate de certificare de încredere
Trebuie remarcat faptul că certificatul CA rădăcină trebuie instalat nu în spațiul de stocare curent al utilizatorului, ci în spațiul de stocare al computerului local, deoarece numai conținutul său acționează asupra tuturor utilizatorilor și conturilor de sistem. Există mai multe moduri de a adăuga un certificat CA la magazinul local de calculatoare.
Deschideți MMC cu drepturi de administrator »adăugați modulul snap-in Certificate» selectați Computer local ca domeniu de aplicare »importați certificatul cerut autorităților de certificare a certificatelor de încredere de încredere. Pentru mai multe informații, consultați TechNet Gestionați certificatele de bază de încredere.
Prin proprietățile certificatului
Porniți un prompt de comandă cu drepturi de administrator „, pentru ca să: \ cale \ la \ cert.crt» deschide fereastra de proprietăți certificat «pentru a apăsa butonul Set» bifați caseta de selectare Afișare magazine fizice «pentru a alege magazia pentru a instala certificatul Autorităților Trusted Root Certification» Computer Local.
Prin linia de comandă
Este cerut CertMgr. cu aceasta trebuie să executați următoarea comandă:
certmgr.exe -add -c "de la: \ path \ to \ cert.crt" -s -r localMachine root
Verificarea revocării certificatelor
Nu am reușit să verificăm dacă acest certificat a fost revocat. O verificare de revocare nu a putut fi efectuată pentru certificat.
Puteți verifica validitatea verificării revocării (CRL sau OCSP) a oricărui certificat cu următoarea comandă:
certutil -url nume.cer
unde name.cer este numele certificatului emis.
Trebuie avut în vedere faptul că verificarea revocării OCSP are succes numai dacă certificatul CA care a emis certificatul verificat este instalat în magazinul de certificate de încredere al computerului local.
Certificarea serviciilor Web de înregistrare a certificatelor
Acestea sunt aceleași Servicii de înregistrare a certificatelor, dacă sunt în limba engleză. Un rol foarte util care permite:
- utilizatorii să solicite certificate fără un administrator
- la cerere, certificatul CA rădăcină
- să execute cereri personalizate speciale, de exemplu pentru servere web care rulează Linux sau alte dispozitive de rețea
- faceți totul pe Internet
- înregistrarea în sine poate funcționa pe un alt calculator decât CA, ceea ce sporește securitatea CA rădăcină
Instalarea și configurarea înregistrării pe Web este simplă și trivială, cu excepția următoarelor puncte
- dacă instalați înscrierea pe un computer diferit de CA, trebuie să urmați pașii descriși în Setările de delegare TechNet pentru articolul Cont Account Web Subscription Certificate. în caz contrar, serviciul nu va funcționa, dând următoarea eroare:
A apărut o eroare neașteptată: serviciul autorității de certificare (CA) nu a fost pornit. A apărut o eroare neașteptată: Autoritatea de certificare.
Solicitați un certificat cu un nume alternativ
Implicit, CA pe Windows Server nu este configurat să emită certificate care conțin SAN. Pentru a activa această caracteristică pe computer cu CA, trebuie să:
certutil -setreg politică \ EditFlags + EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc
Solicitați informații prin intermediul consolei MMC
Cerere prin utilitatea certreq
Un mod mai flexibil și universal de a solicita certificate de la un SAN este următorul, utilizând utilitarul certreq. Pentru a crea un certificat, trebuie să acționați conform următorului algoritm:
[Version]
Semnătura = "$ Windows NT $"
[NewRequest]
Subiect = "CN = server.argon.local, OU = IT, O = Argon, L = Kirov, S = Kirovskaya, C =
KeySpec = 1
KeyLength = 2048
HashAlgoritm = SHA256
Exportabil = TRUE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
RequestType = PKCS10
KeyUsage = 0xa0
ProviderName = "Furnizorul criptografic Microsoft RSA SChannel"
FriendlyName = "server.argon.local cu SAN"
[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.1; Autentificare server
[RequestAttributes]
CertificateTemplate = WebServer
[Extensii]
2.5.29.17 = ""
_continue_ = "DNS = * .argon.com.ru"
_continue_ = "DNS = argon.com.ru"
_continue_ = "DNS = server.argon.local"
_continue_ = "DNS = server"
_continue_ = "DNS = localhost"
2. Pe mașina pentru care solicitați un certificat, executați comanda
certreq -new request.inf
Vi se va cere să salvați fișierul de cerere pregătit în format .req. În același timp, o cheie privată pentru viitorul certificat va fi stocată în magazinul de certificate de computer.
3. Trimiteți cererea către autoritatea de certificare și primiți răspunsul în dosarul .cer. Pentru a face acest lucru, puteți utiliza MMC Authority Authority (și specificați fișierul .req) sau Web Enrollment (în fereastra Advanced query, introduceți conținutul fișierului .req și selectați șablonul serverului web).
4. Instalați certificatul primit pe computerul țintă cu următoarea comandă
certreq -accept request.cer
Practici generalizate
Link-uri utile
"De exemplu, conexiunea la computerul de la distanță este respinsă, dând o eroare:
Nu am reușit să verificăm dacă acest certificat a fost revocat. "
Igor, bună după-amiază!
Am exact această eroare, deși, mi se pare, am pus totul în regulă, nu am putut să înțeleg această problemă?
Pot trimite o captură de ecran unde veți vedea în mod clar modul în care este configurat totul, dar nu știu exact unde să îl trimit.
Vă mulțumim anticipat pentru asistență.
1. Mergeți la computer, când conectați la care există probleme, în fișierul snap-in certificate de computer, exportați certificatul utilizat pentru RDP în fișier (fără cheia închisă).
2. Scoateți acest certificat pe computer, la conectare, de la care este emisă eroarea de verificare a certificatului.
Rulați certutil -url nume.cer
Trebuie să treacă un test de revocare a certificatului, fie prin CRL sau OCSP.
Voi încerca, desigur, dar pentru a face această operațiune pentru utilizatorii 150 este nerealist, ar dori să vadă aceste lucruri practicau în mod automat, în plus, că pentru acest tip de toate înființat, aveți nevoie pentru a înțelege motivele pentru care nu a mers verificarea revocării și pune în aplicare - aceasta este o extremă caz ...
Odată ce încercați să verificați forțat într-un mediu controlat pentru a găsi și elimina cauza. Despre toti utilizatorii, nu am spus;)
C: \ Utilizatori \ administrator> certutil -url c: \ ts.cer
CertUtil: -URL - comanda a fost executată cu succes.
Dazh M-am pierdut, ce altceva de oferit. Să începem cu una simplă.
1. Verificați dacă certificatul de pe terminal este într-adevăr de încredere de către computerul client, întregul lanț de la certificat la CA Root. Și încrederea ar trebui să fie nu la nivelul stocării utilizatorului, ci la nivelul calculatorului.
2. Dacă există mașini care nu au acces la această problemă, comparați config-urile cu pacienții.
3. Dacă nu merită deja, încercați să implementați Responderul online. Dar, în același timp, trebuie să re-emiteți certificatele, astfel încât să conțină informații despre el.
Desigur, putem, dar cred că discuția publică poate fi utilă altor cititori.
Acum, în acest caz, puteți pune capturi de ecran ale proprietăților certificatelor sau ale certificatelor în sine. Dacă sunteți preocupat de confidențialitate, puteți elimina linkul în formularul de feedback.
1. Salvați pe PC și verificați valabilitatea cu certutil.
2. Salvați pe PC și importați "computerul de încredere" în depozit, doar pentru distracție
Dacă, ca urmare a acestor acțiuni, nu se descoperă nimic nou, apoi se transmit integral certificatele complete, fără chei private.
Ei bine, nu există nici un fel ...
4. Dezactivați verificarea LCR CRL pentru RDP
5. Prin GPO, instalați certificatele TS auto-semnate pe computerele client ca cele de încredere.
"Atunci când instalați un CA într-un domeniu Active Directory, politicile de grup trebuie să fie create în mod implicit care atribuie încrederea clienților CA rădăcină"
"Dar au fost revocate de către autoritatea de certificare"
Aparent, există o greșeală și înseamnă "nu".
"CRL (Lista de Revocare a Certificatelor) pe serverul web, actualizată periodic"
Personal, am creat centre de certificare pentru a publica CRL-uri în DFS (cu replicare, dacă este cazul) de unde sunt distribuite liniștit de IIS - nu sunt necesare "actualizări regulate" - totul este automat. Un exemplu de astfel de setare pe care l-am arătat aici.
Care este dificultatea de a face același lucru atunci când numele de domeniu extern este diferit de cel intern? Furnizarea "transparenței" sufixului domeniului, din prezentarea mea, este descrisă aici.
"Trebuie reținut faptul că verificarea revocării OCSP are succes numai dacă certificatul CA care a emis certificatul de încredere este instalat în magazinul de certificate de încredere al calculatorului local"
Aș dori, de asemenea, să adaug că pentru o validare OSCP de succes va avea loc numai în cazul în care acesta ocsp-server are acces la CRL-fișierele - care este în cazul în care este nevoie de informații, economisind clientul de descărcare a acestora;).
"Aceștia sunt aceleași Servicii de înregistrare a certificatelor, dacă sunt în limba engleză. Rolul foarte util "
Și aș spune că rolul este inutil și am refuzat personal să o folosesc mult timp. Podans, apropo, este în acord cu această opinie (aici și aici) :).
"În mod implicit, CA pe Windows Server nu este configurat să emită certificate care conțin un SAN."
Iluzie universală;). CAs bine da SAN necertificat și fără includerea acestei opțiuni - o dată pe Vadim am „crezut“, dar link-ul anterior însuși a admis eroarea și efectele nocive ale acestui pavilion său.
Absolut nu neapărat;).
"Un mod mai flexibil și mai universal de a solicita certificate de la un SAN este următorul, utilizând utilitarul certreq."
Din cauza universalului nu se poate argumenta, dar în detrimentul flexibilității complet dezacord :). În opinia mea, cea mai flexibilă este cererea prin consola MMC în noile sisteme. Și pur și simplu și convenabil și vizual și fără crearea de fișiere cu o grămadă de parametri pe care nu le păstrați într-un cap și este necesar să se adreseze în avans șabloanelor pregătite.
"Trimiteți o cerere autorității de certificare și primiți un răspuns. Pentru a face acest lucru, puteți utiliza MMC Authority Authority (și specificați un fișier .req) sau Web Enrollment (în fereastra Advanced query, inserați conținutul fișierului .req și selectați șablonul serverului web). "
Prefer, dacă este necesar, să trimit o cerere cu comanda "certreq -Submit -attrib" certificatetemplate: WebServer "Request.req Response.cer".
"Dacă CA este pe Windows, integrat cu AD, atunci trebuie să îl configurați pentru a publica CRL / AIA în AD"
De asemenea, o mare concepție greșită;). Aceste linkuri din scenariile Internet interferează și cea mai bună opțiune este să le "văd" complet din certificate - să lase doar legături publice HTTP.
Puteți să învățați cum să faceți acest lucru nu cu o companie de domeniu?