Cu cât infrastructura de pe Windows Server devine mai integrată, complexă și mai sigură, cu atât se bazează mai mult pe PKI (Infrastructura cheii publice) pe lângă Active Directory tradițional pentru a oferi încredere și autentificare între computere, utilizatori și servicii. Active Directory Certificate Services este o implementare PKI de la Microsoft care constă din următoarele elemente:
- Autoritatea de certificare (CA, Autoritatea de certificare), rădăcină și subordonați
- relație de încredere generală în CA
- Certificate emise de CA pentru computere, utilizatori și servicii
- diverse servicii de suport PKI
- liste de revocare a certificatelor (CRL)
- răspuns online (Online Responder, o alternativă mai progresivă la CRL)
- Înscriere web (un instrument pentru solicitarea de certificate prin web)
Cerere automată de certificat
Instalarea manuală a certificatului CA rădăcină
Dacă într-un Active Directory și un mediu de rețea locală încrederea în autoritatea de certificare rădăcină este configurată automat, atunci pentru ca computerele aflate la distanță din afara domeniului să aibă încredere în CA, trebuie să instalați certificatul CA în Magazinul lor de încredere. centrii radiculari certificare. În caz contrar, fie vor fi emise avertismente cu privire la pericolul potențial al unui certificat semnat de o persoană necunoscută, fie conexiunile la un astfel de server vor fi respinse cu totul, ca, de exemplu, în cazul Remote Desktop Services Gateway va fi afișată următoarea eroare :
Computerul nu poate verifica identitatea Remote Desktop Gateway „server.argon.com.ru”. Conectarea la servere fără acreditări este nesigură. Acest computer nu poate verifica identitatea RD „server.argon.com.ru”. Nu este sigur să vă conectați la servere care nu pot fi identificate. Acest certificat nu a putut fi verificat prin urmărirea lui la o certificare de încredere autoritate
Vă rugăm să rețineți că certificatul CA rădăcină nu ar trebui să fie instalat în stocare utilizator actual, și în depozit calculator local, deoarece numai conținutul său afectează toți utilizatorii și conturile de sistem. Există mai multe modalități de a adăuga un certificat CA la magazinul local de computere.
Prin MMC
Prin proprietățile certificatului
Rulați un prompt de comandă cu drepturi de administrator » apelați-l cu:\path\to\cert.crt » se va deschide fereastra cu proprietățile certificatului » faceți clic pe butonul Instalare » bifați caseta Afișare stocări fizice » selectați un spațiu de stocare pentru instalarea certificatului Trusted Root Certification Autorități » Calculator local.
Prin linia de comandă
Veți avea nevoie de utilitarul CertMgr, folosindu-l trebuie să rulați următoarea comandă:
certmgr.exe -add -c "c:\path\to\cert.crt" -s -r localMachine root
Verificarea revocării certificatului
Unele servicii de rețea (Remote Desktop, DirectAccess, L2TP și SSTP VPN) care utilizează certificate pentru autentificarea serverului necesită verificarea acestor certificate pentru a vedea dacă sunt legitime (dar au fost revocate de o autoritate de certificare). Într-un mediu de rețea locală, nu există probleme cu astfel de verificări, deoarece listele de revocare a certificatelor sunt publicate în Active Directory și la adresele locale ale autorității de certificare.
Situația se schimbă dacă încearcă să verifice legitimitatea certificatului de pe Internet, unde, desigur, nu sunt disponibile nici Active Directory, nici adresele locale ale autorităților de certificare. Și cel mai neplăcut lucru este că încrederea sistemului într-un certificat emis de un centru de încredere, dar neverificat pentru legitimitate, este chiar mai mică decât într-unul necunoscut sau autosemnat. De exemplu, conexiunea desktop la distanță este respinsă cu următoarea eroare:
Nu a fost posibil să se verifice dacă acest certificat a fost revocat. O verificare de revocare nu a putut fi efectuată pentru certificat.
Pentru a rezolva problema de a face disponibilă verificarea revocării certificatelor de pe Internet, trebuie să publicați oricare dintre următoarele servicii:
- CRL (Certificate Revocation List) pe serverul web, actualizat regulat
- Online Responder (un răspuns online disponibil începând cu Windows Server 2008 Enterprise edition), care funcționează aproximativ la fel ca versiunea anterioară, dar folosind un protocol OCSP mai avansat (dar prin HTTP)
Pentru ca ambele opțiuni să funcționeze, este necesar ca autoritatea de certificare să fi configurat în prealabil adresele acestor servicii accesibile de pe Internet, deoarece aceste adrese sunt codificate hard în fiecare certificat emis.
Pentru instrucțiuni despre configurarea unei CA pentru a găzdui CRL-uri pe Internet, consultați articolul TechNet Configurarea revocării certificatelor. Voi observa doar un truc: dacă domeniul dvs. are un nume DNS accesibil de pe Internet (adică argon.com.ru, și nu argon.local), iar opțiunea de înregistrare web este instalată pe serverul cu CA rădăcină , atunci CA este deja configurată să își publice CRL la http://server.argon.com.ru/CertEnroll. Prin urmare, pentru ca CRL să funcționeze pe deplin, este suficient să publicați pur și simplu un port HTTP pe Internet sub numele de domeniu server.argon.com.ru.
Configurarea și publicarea Online Responder este puțin mai complexă, dar este tratată în detaliu în articolele TechNet Online Responder și Setting Up Online Responder Services in a Network. Nu există trucuri sau setări implicite aici, instalați sincer rolul pe serverul dorit, configurați acest rol, publicați un site HTTP pe Internet și configurați CA să includă informații despre Online Responder în certificatele publicate.
Puteți verifica dacă verificarea revocării (CRL sau OCSP) a oricărui certificat funcționează corect utilizând următoarea comandă:
certutil -url name.cer
unde nume.cer este numele certificatului emis.
Vă rugăm să rețineți că verificarea revocării OCSP reușește numai dacă certificatul CA care a emis certificatul verificat este instalat în depozitul de certificate de încredere al computerului local.
Servicii web de înregistrare a certificatelor
Acestea sunt, de asemenea, servicii web de înregistrare a certificatelor, în limba engleză. Un rol foarte util care vă permite să:
- Solicitați certificate de către utilizatori fără participarea administratorului
- furnizați un certificat CA rădăcină la cerere
- executați solicitări speciale deja pregătite (Custom Request), de exemplu pentru serverele web care rulează Linux sau alte dispozitive de rețea
- fă-o peste tot pe Internet
- Web Enrollment în sine poate rula pe un alt computer decât CA, ceea ce crește securitatea CA rădăcină
Instalarea și configurarea Web Enrollment este simplă și trivială, cu excepția următoarelor puncte
- Dacă instalați Web Enrollment pe un alt computer decât CA, trebuie să urmați pașii descriși în articolul TechNet Configurarea setărilor de delegare pentru contul de serviciu web de înregistrare a certificatelor, altfel serviciul nu va funcționa, producând următoarea eroare:
A apărut o eroare neașteptată: Serviciul Autoritate de certificare (CA) nu rulează. A apărut o eroare neașteptată: Serviciul Autorității de Certificare nu a fost pornit.
- aceeași eroare va fi afișată dacă Web Enrollment rulează pe același server ca ISA Server / Forefront TMG, în regulile lor de sistem trebuie să dezactivați Aplicarea strictă a conformității RPC și să permiteți protocolul RPC în rețeaua internă.
- Când publicați înregistrarea web pe Internet, trebuie să activați cerința SSL pentru aplicația web CertSrv în consola IIS
Solicitați un certificat cu un nume alternativ
O întrebare presantă la publicare servicii interneîntreprinderi pe Internet - crearea de certificate cu o listă de nume alternative DNS (Subject Alternative Name, SAN).
În mod implicit, CA pe Windows Server nu este configurat să emită certificate care conțin un SAN. Pentru a activa această funcție pe un computer cu un CA, trebuie să rulați:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc
Solicitare prin consola MMC
Începând cu Windows Server 2008, a devenit posibilă solicitarea unui certificat de la un SAN prin consola Certificates MMC, pentru aceasta...
- În consola de administrare CA, pentru șablonul de certificat Web Server, atribuiți drepturi de solicitare și citire contului computerului care solicită certificatul.
- Computerul de pe care este creată cererea trebuie să facă parte din domeniul în care este publicat CA
- Creați o solicitare utilizând un șablon de server web → în proprietățile cererii, specificați o listă de nume DNS alternative în Subiect → Nume suplimentar → fila DNS.
Solicitați prin utilitarul certreq
O modalitate mai flexibilă și mai versatilă de a solicita certificate de la un SAN este următoarea, folosind utilitarul certreq. Pentru a crea un certificat trebuie să urmați următorul algoritm:
1. Pregătiți un fișier text request.inf pentru o cerere de certificat cu următorul conținut.
Semnătură="$Windows NT$"
Subiect = "CN=server.argon.local, OU=IT, O=Argon, L=Kirov, S=Kirovskaya, C=RU"
KeySpec = 1
Lungime cheie = 2048
HashAlgorithm = SHA256
Exportabil = TRUE
MachineKeySet = TRUE
SMIME = FALS
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
RequestType = PKCS10
KeyUsage = 0xa0
ProviderName = „Microsoft RSA SChannel Criptographic Provider”
FriendlyName = „server.argon.local cu SAN”
OID=1.3.6.1.5.5.7.3.1; Autentificare server
CertificateTemplate = WebServer
2.5.29.17 = „(text)”
_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 se presupune că se solicită certificatul, executați comanda
certreq -new request.inf
3. Trimiteți o cerere către autoritatea de certificare și primiți un fișier .cer ca răspuns. Pentru a face acest lucru, puteți utiliza consola de management MMC a Autorității de certificare (și specificați fișierul .req) sau Înscrierea web (inserați conținutul fișierului .req în fereastra de solicitare avansată și selectați un șablon de server web).
4. Instalați certificatul primit pe computerul țintă cu următoarea comandă
certreq -accept request.cer
5. PROFIT. Ca urmare a acțiunilor descrise, în depozitul de certificate al computerului va fi creat un certificat cu cheie privată, potrivit pentru autorizarea serverului folosind mai multe nume scrise în fișierul .inf.
Cele mai bune practici generalizate
Voi da un exemplu de implementare rațională a PKI într-o întreprindere pentru a sprijini serviciile avansate ale Windows Server 2008 R2
- O autoritate de certificare rădăcină este implementată pe controlerul de domeniu
- Dacă organizația este mare, atunci au fost create mai multe CA subordonate, alocate în anumite scopuri (în funcție de scopul certificatului, de ramură a organizației, de distribuire a încărcăturii...)
- În politicile de grup, încrederea în CA rădăcină și cererea automată pentru certificate de computer de domeniu sunt configurate
- Pe computerul membru al domeniului edge, următoarele servicii sunt implementate și publicate folosind Forefront TMG pe Internet:
- Înregistrare web pentru instalarea și solicitarea certificatului CA certificate personale de pe computere non-domeniu
- Responder online pentru verificarea revocării certificatului folosind protocolul OCSP
- Următoarele servicii de rețea sunt publicate pe Internet folosind certificate cu SAN, bazându-se pe utilizarea certificatelor și verificarea revocării acestora:
- Gateway Desktop la distanță
- Outlook Web Access
- DirectAccess
- SharePoint
Link-uri utile
- Instalarea Autorității de Certificare – blogul lui Vadims Podans
- OCSP (partea 1), OCSP (partea 2) – blogul lui Vadims Podans
| Titlu | |
|---|---|
| Etichete | , |
| Publicat |
Bună ziua!
Cred că aproape fiecare utilizator (mai ales recent) a întâmpinat o eroare în browser care afirmă că certificatul unui astfel de site nu este de încredere și o recomandare de a nu-l vizita.
Pe de o parte, acest lucru este bun (la urma urmei, browserul și, în general, popularizarea unor astfel de certificate, ne asigură securitatea), dar, pe de altă parte, o astfel de eroare apare uneori chiar și pe site-uri foarte cunoscute (pentru exemplu, Google).
Esența a ceea ce se întâmplă și ce înseamnă?
Faptul este că atunci când vă conectați la un site pe care este instalat protocolul SSL, serverul transmite un document digital către browser ( certificat) că site-ul este autentic (și nu un fals sau o clonă a ceva de acolo...). Apropo, dacă totul este în regulă cu un astfel de site, atunci browserele le marchează cu un lacăt „verde”: captura de ecran de mai jos arată cum arată în Chrome.
Cu toate acestea, certificatele pot fi eliberate de organizații binecunoscute (Symantec, Rapidssl, Comodo etc.) , și oricine în general. Desigur, dacă browserul și sistemul dvs. „nu știu” cine a emis certificatul (sau există suspiciunea că acesta este corect), atunci apare o eroare similară.
Aceste. Adică atât site-urile complet albe, cât și cele care sunt cu adevărat periculoase de vizitat pot intra în distribuție. Prin urmare, apariția unei astfel de erori este un motiv pentru a arunca o privire atentă la adresa site-ului.
Ei bine, în acest articol vreau să subliniez mai multe modalități de a elimina o astfel de eroare dacă a început să apară chiar și pe site-uri albe și cunoscute (de exemplu, pe Google, Yandex, VK și multe altele. Nu vei refuza să vizitați-i, vrei?).
Cum se rezolvă eroarea
1) Atenție la adresa site-ului
Primul lucru de făcut este să acordați atenție adresei site-ului (este posibil să fi introdus din greșeală adresa URL greșită). De asemenea, uneori acest lucru se întâmplă din cauza vinei serverului pe care se află site-ul (poate că, în general, certificatul în sine este pur și simplu depășit, deoarece este emis pentru o anumită perioadă de timp). Încercați să vizitați alte site-uri, dacă totul este în regulă cu ele, atunci cel mai probabil problema nu este cu sistemul dvs., ci cu site-ul respectiv.
Exemplu de eroare „Certificatul de securitate al site-ului nu este de încredere”
Cu toate acestea, remarc că dacă eroarea apare pe un site foarte cunoscut în care dvs. (și mulți alți utilizatori) aveți deplină încredere, atunci există o probabilitate mare de apariție a unei probleme în sistemul dvs....
2) Verificați data și ora setate în Windows
Al doilea punct este că o eroare similară poate apărea dacă ora sau data sunt setate incorect în sistemul dvs. Pentru a le corecta și a le clarifica, faceți clic pe „ora” din bara de activități Windows (în colțul din dreapta jos al ecranului). Vedeți captura de ecran de mai jos.
După ce setați ora corectă, reporniți computerul și încercați să redeschideți browserul și site-urile din acesta. Eroarea ar trebui să dispară.
De asemenea, vă atrag atenția asupra faptului că, dacă vă pierdeți timpul în mod constant, bateria de pe placa de bază este probabil moartă. Este o „tabletă” mică, datorită căreia computerul își amintește setările pe care le-ați introdus, chiar dacă îl deconectați de la rețea (de exemplu, se calculează cumva aceeași dată și oră?).
3) Încercați să actualizați certificatele rădăcină
O altă opțiune pentru a încerca să rezolvați această problemă este să instalați o actualizare a certificatului rădăcină. Actualizările pot fi descărcate de pe site-ul Microsoft pentru diferite sisteme de operare. Pentru sistemele de operare client (adică, pentru utilizatorii casnici obișnuiți), aceste actualizări sunt potrivite:
4) Instalarea certificatelor „de încredere” în sistem
Deși această metodă funcționează, aș dori să vă avertizez că „poate” deveni o sursă de probleme în securitatea sistemului dumneavoastră. Cel puțin, vă sfătuiesc să recurgeți la aceasta doar pentru site-uri atât de mari precum Google, Yandex etc.
Pentru a scăpa de eroarea asociată cu lipsa de încredere a certificatului, trebuie folosit un specialist. pungă de plastic Autoritatea de certificare primară GeoTrust .
Apropo, pentru a descărca GeoTrust Primary Certification Authority:
Acum trebuie să instalați certificatul descărcat în sistem. Vă voi spune pas cu pas cum se face acest lucru mai jos:
5) Acordați atenție utilităților antivirus
În unele cazuri, această eroare poate apărea din cauza faptului că un program (de exemplu, un antivirus) scanează traficul https. Acesta este ceea ce vede browserul că certificatul primit nu se potrivește cu adresa de la care a venit și ca urmare apare un avertisment/eroare...
Prin urmare, dacă aveți instalat un antivirus/firewall, verificați și dezactivați temporar setarea de scanare a traficului https (vezi exemplul de setări AVAST în captura de ecran de mai jos).
asta e tot ce am...
Pentru completări pe această temă - un merci special!
Toate cele bune!
Am rezolvat cu succes o problemă cu terminalele zilele trecute. Poate că va fi util pentru altcineva, iar în cazul, de exemplu, amnezie, îmi va fi util să-mi amintesc :)
Esența problemei este următoarea. Există servere terminale pe Windows 7 (și acum există și Win8 - și poate chiar și această soluție este potrivită pentru versiunile de server).
Adică, conexiuni prin Remote Desktop Protocol (RDP) versiunile 7 și 8 (versiunile binare 6.1 și, respectiv, 6.2) la serviciile Remote Desktop.
Acum, conectarea la ele necesită ca serverul să aibă un certificat și să îl verifice cu clientul.
Serverul creează automat un certificat autosemnat atunci când vă conectați la el (sau dacă este șters „în mod accidental”).
Dar, în același timp, în momentul conexiunii, clienții primesc un avertisment „Nu se poate verifica autenticitatea computerului de la distanță: certificatul a fost emis de o autoritate de certificare neîncrezătoare” - un beneficiu care poate fi dezactivat pentru moment. U servere Nu există o astfel de problemă pe Windows XP - dar clienții din XP deja înjură.
Nu este vorba că ar fi o astfel de problemă, este doar un inconvenient minor. Dar nu face munca zilnică deosebit de confortabilă. Mai ales administratorul - care de mai multe ori pe zi și se agață de diferite mașini...
Aşa. Este necesar să înlocuiți certificatele „serverelor” cu cele „corecte”.
Cum să faci certificatele „corecte” este o poveste separată - o postare separată.
Am făcut-o prin openssl + EasyRSA (1.0 - sau 2.0 care vine cu openvpn - dar a trebuit să-l modific puțin - dar principalul lucru este să-mi dau seama de configurații - heh).
Probabil că folosind instrumente MS (același certutil sau GUI) ar fi posibil să obțineți cheile mult mai ușor, dar am săpat puțin în acest x509 - acum înțeleg puțin mai bine scopul dansului cu tastele de tamburin pentru openvpn .. Numai CA-urile, fără să iau în calcul autoritățile de certificare intermediare deocamdată, mi-am dat seama cu ei și am muncit mult :)
Este posibil (și de dorit) să obțineți certificate de la autorități de certificare terțe de încredere - dar acestea nu vă vor costa mulți bani - și nu vă vor lăsa să învățați din certificate.
Să continuăm. În timpul procesului de keygeneza ar trebui să se obțină următoarele lucruri:
- Certificat CA auto-realizat în format x509/CER/base64 - să fie un fișier ca.crt .
- cheie de server pkcs12/pfx cu EKU „conexiune desktop la distanță” sau „server TLS” semnat de un certificat care este verificat prin CA menționată mai sus - acesta va fi un fișier test.p12 cu parola" qwe " - cheie hash - 01:23:..:cd:ef .
- Server HTTP care furnizează certificate intermediare, rădăcină și răspunsuri la acestea (crl).
Fără acest punct, RDP nu ar putea fi făcut să funcționeze fără să înjure - așa că planificați-vă din timp; Din fericire, niște mangoose vor fi suficiente - pentru că deocamdată CA noastră trebuie să servească doar fișiere statice mici și destul de rar.
Tot ceea ce urmează necesită o consolă administrativă (cu drepturi ridicate) pe serverul experimental.
- Am plasat certificatul rădăcină în depozitul de certificate rădăcină de încredere. Este simplu - folosim utilitarul standard de sistem:
certutil -addstore root ca.crt
- Punem cheia serverului în stocarea personală (dar a „calculatorului local”).
Există o nuanță aici. Atunci când pur și simplu importați o cheie, aceasta se poate încadra în stocarea personală a utilizatorului - și chiar cu drepturi incorecte. Cu importul avansat - prin mmc și snap-in-ul "Certificate / Calculator local" - va trebui să acordați drepturi de acces la cheia privată Serviciului de rețea - în numele căruia funcționează termserv - din nou, o mulțime de scrisori și imagini vor trebuie să descrie toate acestea. Cea mai simplă soluție găsită a fost prin utilitarul WinHttpCertCfg.exe din .WinHttpCertCfg -a NetworkService -c LOCAL_MACHINE\MY -i test.p12-p qwe
Da, dacă cheia a fost deja importată într-un fel diferit, puteți acorda drepturile corecte cu comanda:
WinHttpCertCfg.exe -un serviciu de rețea-c LOCAL_MACHINE\MY -g-s SUBJ
unde SUBJ acesta este subiectul cheii - pentru ca utilitarul să o găsească - și cel mai probabil se va potrivi cu numele computerului - trebuie doar să specificați %COMPUTERNAME%. - Forțăm serverul terminal să dea cheia noastră în loc de cea autosemnată. Trebuie doar să specificați hash-ul cheii dorite în registry. Nu este nevoie să reporniți serviciul, cu atât mai puțin computerul.
reg add „HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp”/v SSLCertificateSHA1Hash /t REG_BINARY /d 0123456789..DEF
Ei bine, asta e tot, de fapt. Data viitoare când clientul se conectează, clientul nu va primi o notificare despre certificatul de server incorect. Puteți activa din nou notificările despre acest coșmar sau chiar interziceți conectarea la astfel de servere.
Nu este totul foarte simplu?
O zi bună, dragi oaspeți! În acest articol am dori să reamintim încrederea certificatelor în Browsere, datorită și. Mulți oameni nu înțeleg asta Certificat SSL utilizatorul este doar o parte a întregului „lanț de certificate”. Să vorbim despre certificatele intermediare și rădăcină. SSL (mai precis, TLS) este o tehnologie despre care majoritatea utilizatorilor nu știu aproape nimic. Chiar și cei care îl achiziționează, de obicei, nu știu nimic altceva decât au nevoie de un certificat SSL și trebuie să îl instaleze pe serverul lor pentru a activa HTTPS pe site-ul lor. Deci, să începem!