Crearea propriului CA pentru un intranet

Dacă infrastructura dvs. este mică , multe dintre detaliile despre executarea unui CA (de exemplu, CRL-uri și altele) pot fi probabil ignorate. În schimb, tot ce trebuie să vă faceți griji este să semnați certificate.

Există o multitudine de instrumente care vă vor gestiona acest proces. Am scris chiar unul acum mulți ani. Dar cel pe care îl recomand dacă doriți ca ceva cu adevărat simplu să fie easy-rsa din proiectul OpenVPN. Este o învelitoare foarte subțire în jurul instrumentului OpenSSL din linia de comandă. Dacă veți gestiona o mulțime de certificate și veți avea de-a face cu revocarea și alte lucruri, veți dori un utilitar mult mai complex și complet cu caracteristici. Există deja mai multe sugestii oferite deja, așa că, în schimb, voi rămâne cu elementele de bază ale a ceea ce încercați să realizați.

Dar iată procedura de bază. O voi explica cu OpenSSL , dar orice sistem va funcționa.

Începeți prin crearea CA „rădăcină” – va fi un certificat autosemnat. Există mai multe modalități de a face acest lucru; acesta este unul. Vom face un certificat de 10 ani cu o cheie de 2048 biți.Ajustează numerele după caz. Ați menționat că sunteți îngrijorat de algoritmul de hash, așa că am adăugat -sha256 pentru a mă asigura că este semnat cu ceva acceptabil. Criptez cheia folosind AES-256, dar asta este opțional . Vi se va cere să completați numele certificatului și altele; aceste detalii nu sunt deosebit de importante pentru un CA rădăcină.

# First create the key (use 4096-bits if that"s what floats your boat) openssl genrsa -aes256 -out root.key 2048 # Then use that key to generate a self-signed cert openssl req -new -x509 -key root.key -out root.cer -days 3652 -sha256 

Dacă ați criptat cheia în primul pas, va trebui să furnizați parola pentru folosiți-l în al doilea. Verificați certificatul generat pentru a vă asigura că în „Constrângeri de bază” apare „CA: TRUE”. Acesta este cu adevărat singurul element important de care trebuie să vă faceți griji:

openssl x509 -text < root.cer 

Bine. OK, acum să semnăm un certificat. Vom avea nevoie de o altă cheie și de data aceasta o cerere. Veți fi întrebat din nou despre numele și adresa dvs. Ce câmpuri completați și ce furnizați depinde de dvs. și de aplicația dvs., dar câmpul care contează cel mai mult este „numele comun”. Acolo vă furnizați numele de gazdă sau numele de conectare sau orice altceva care va atesta acest certificat.

# Create new key openssl genrsa -aes256 -out client1.key 2048 # Use that key to generate a request openssl req -new -key client1.key -out client1.req # Sign that request to generate a new cert openssl x509 -req -in client1.req -out client1.cer -CA root.cer -CAkey root.key -sha256 -CAcreateserial 

Rețineți că acest lucru creează un fișier numit root.srl la păstrați-ne numerele de serie drepte. Semnalizatorul -CAcreateserial spune openssl să creeze acest fișier, astfel încât să îl furnizați pentru prima cerere pe care o semnați și apoi niciodată mai mult. Și din nou, puteți vedea unde pentru a adăuga argumentul -sha256.

Această abordare – făcând totul manual – nu este în opinia mea cea mai bună idee. Dacă rulați o operație considerabilă , atunci veți dori probabil un instrument care să vă poată urmări toate certificatele.

În schimb, scopul meu era să vă arăt că ieșirea dorită – certificatele au fost semnate așa cum doriți – nu depinde de instrumentele pe care le utilizați, ci mai degrabă de opțiunile pe care le oferiți acelor instrumente. Majoritatea instrumentelor pot genera o mare varietate de configurații, atât puternice, cât și slabe, și depinde de dumneavoastră să furnizați numerele sunt potrivit. Valorile implicite învechite sunt par pentru curs.

Comentarii

• Este important ‘ să rețineți că, atunci când semnezi un certificat de client, este doar porțiunea publică . Nicio cheie privată nu ar trebui să fie transmisă sau generată de CA.
• Puteți extinde răspunsul la crearea unui certificat CA intermediar? Mulțumim.
• @Andr é Certificatele intermediare sunt doar certificate normale, cu basicConstraints = CA:TRUE setat în atributele lor extinse. Nimic magic, doar un alt certificat.
• @tylerl Băi, tu rock.
• Acest răspuns este FANTASTIC și a fost foarte util, dar am o actualizare din 2017 de adăugat. Chrome și altele necesită acum extensia x509v3 subjectAlternativeName; în caz contrar, consideră că certificatul este nevalid, chiar și cu un certificat rădăcină CA instalat corespunzător pe sistem. M-am chinuit de ceva timp să vin cu soluția potrivită. Această pagină a fost de neprețuit pentru mine și a rezolvat ultima piesă a puzzle-ului pentru mine: cmrg.fifthhorseman.net/wiki/SubjectAltName . OMI, adăugarea SAN la semnare, spre deosebire de cerere, este mai ușoară și mai asemănătoare cu ceea ce fac de fapt autoritățile publice de certificare.

Dacă doriți cu adevărat să fiți CA, țineți cont de implicațiile de securitate ale acestui lucru.

1. Cheia privată utilizată pentru a genera CA rădăcină pentru intranetul dvs. ar trebui literalmente să fie închis într-un seif. Și accesul la sigurul menționat trebuie monitorizat fizic.
2. Folosirea unui CA rădăcină auto-semnat îi obligă pe utilizatori să nu aibă încredere doar că efectuați diligența cu protecția sigură a cheilor, ci să introduceți și o rădăcină inițial neacredibilă. pot intra în lanțul lor de certificate.
3. Acest lucru încalcă și funcționalitatea de capsare OSCP în ceea ce privește verificarea externă a lanțului de certificate, motiv pentru care serviciile de gestionare a identității există în primul rând.

Câțiva ar argumenta raționamentul din spatele gestionării propriei CA, cum ar fi; este pentru un intranet corporativ în care o parte a versiunilor noastre de desktop includ rădăcina ca sau este pentru un număr mic de utilizatori.

Deși nu este neapărat greșit să o faci și poate să-ți permită unele beneficii anulați lanțul de verificare pentru care a fost creat managementul identității bazat pe certificat.

Dacă decideți să vă implementați propriul root ca, asigurați-vă că urmați aceleași practici de securitate ca orice alte aplicații ca ca root. ultimul lucru pe care l-ai dori să se întâmple este ca cineva să compromită cheia privată utilizată pentru root ca și să înceapă să semneze certificate pentru campaniile de phishing împotriva clienților tăi.

Există o mulțime de ghiduri de bune practici disponibile pentru aceasta, NIST ( institutul național pentru standarde și tehnologie) este un grup colaborativ care asistă în diferite standarde pentru subiecte de securitate computerizată.

Citire recomandată:
Audit (PDF)
Recuperare în caz de dezastru (PDF)
Sisteme de chei publice (PDF)
Sans institut cu privire la implementări PKI mai mici

Ok Văd că v-ați actualizat întrebarea pentru a fi mai specifică.

Două documente pentru configurarea fișierului openssl.cnf pentru specificul CA:

https://www.openssl.org/docs/apps/ca.html

https://www.openssl.org/docs/apps/config.html

Îmi dau seama că este posibil să nu fie răspunsul pe care îl dorești, dar pentru că mediul și cerințele tuturor sunt diferite, vei merge trebuie să definiți un domeniu de aplicare pentru implementarea CA pentru un bun exemplu de configurare.

Comentarii

• Acolo ‘ nu există niciun motiv pentru care propria dvs. CA nu poate ‘ să facă OCSP. Chiar și linia de comandă OpenSSL o poate face și că ‘ s despre cea mai mică bară posibilă.
• linkurile openssl sunt acum 404

Acolo nu este o modalitate de a face acest lucru pur și simplu. există câteva instrumente care vă pot ajuta să începeți cu ușurință.

ca:

• XCA
• EJBCA
• openssl

niciunul dintre ele nu este un PKI complet, în afară de posibil EJBCA, dar acest lucru nu este banal pentru configurare.

• XCA este un mic instrument frontend pentru a obține o interfață grafică pentru a genera, semna și revoca certificate.
• EJBCA sau Enterprise Java Beans Certificate Authority este o aplicație web JBOSS / Jetty care poate realiza infrastructura PKI completă pentru o întreprindere.
• openssl este instrumentul de bază pentru linia de comandă. poate face toate bițele offline ale unei CA, dar nici una dintre verificări (scoase din cutie). vă puteți crea propriile verificatoare OCSP, dar trebuie să creați singur codul „online”.

Dacă tot ce căutați este o configurare openssl adecvată. XCA vă poate ajuta să le generați. (are o caracteristică de export openssl config

Comentarii

• EJBCA are acum o imagine VM pe care o puteți utiliza. În caz contrar ” nu este banal pentru configurare ” poate fi considerat o subevaluare. Este practic un imens script ant care încearcă să configureze ( JBoss) server de aplicații care poate (și în cazul meu se va ) defecta.
• imaginea VM are sau scopuri de evaluare, așa că nu aș recomanda-o pentru un server de producție.
• S-ar putea să mă uit la XCA. EJBCA nu este cu siguranță ‘ o opțiune – o interfață web adaugă o suprafață de atac inutilă și este mai greu de configurat. Cu siguranță prefer să folosesc doar openssl totuși.
• @Andr é în ceea ce privește EJBCA, poate fi folosit și din linia de comandă, deci ați câștigat ‘ nu trebuie să expună interfața web. Dar ‘ este un lucru la nivel de întreprindere și, probabil, depășește scopurile dvs. es (și spun asta ca pe cineva care își câștigă existența lucrând cu el).

Pentru unii fundal bun, vă rugăm să consultați prezentarea mea Cum să vă construiți și să vă operați propriul centru de gestionare a certificatelor de mediocritate . Esențialul prezentării este că cel mai necesar lucru nu este o listă a comenzilor de executat, ci mai degrabă o înțelegere profundă a tuturor diferitelor controale care intră în operarea unei CA comerciale, modul în care interacționează împreună, impactul exact al eliminării oricărui una dintre ele, impactul cumulativ al eliminării mai multor dintre ele și controalele atenuante necesare pentru a compensa securitatea redusă.

Acesta este motivul pentru care nu există un „răspuns canonic despre înființarea unei CA simple”. parcurgeți întreaga rută ISO, începând cu o petrecere de semnare a cheii, certificate rădăcină duplicate aerodistinse și boltite, semnatari intermediari multipli, servere de revocare etc. etc. sau trebuie să elaborați un compromis bazat pe costul / beneficiul și riscul unic profilul companiei este dispus să accepte. Oricine are suficientă abilitate și experiență pentru a face această evaluare prin definiție, nu are nevoie de fișa de înșelăciune. Aceștia pot analiza sintaxa corectă a comenzii pe baza unei înțelegeri profunde a funcției de afaceri care trebuie îndeplinită și a primitivelor de securitate utilizate pentru a implementa această cerință.

În prezentare sunt povești din angajamentele reale ale magazinelor care au mers pe acest drum și au greșit îngrozitor. În unele cazuri, evaluarea mea a raportat că absolut nimic din ce pot face cu securitatea dvs. middleware nu poate depăși slăbiciunile inerente ale CA interne. Oricine din SUA ar trebui să-și dea seama că probabil cumpără servicii de la cel puțin unul dintre furnizorii la care se referă prezentarea. Acestea sunt bănci, uniuni de credit, asigurători de sănătate, comercianți cu amănuntul și multe altele.

Întrucât recomandările să fie „corecte”, este necesar ca persoana care răspunde să facă presupuneri majore cu privire la profilurile dvs. de risc acceptabile și să faceți ipoteze majore cu privire la gradul în care dvs. și ideile lor de risc sunt aliniate și sincronizat, însăși propunerea este riscantă. În majoritatea acestor cazuri, evaluarea adecvării tutorialelor furnizate are mai mult de-a face cu prezentarea decât cu nivelul eficient de securitate rezultat din urmarea procedurilor lor. Dacă este bine organizat și clar articulat, acest lucru contează MULT mai mult decât dacă este eficient. Alegem foaia de înșelăciune canonică care arată cel mai bine pentru noi.

Din aceste motive, nu cred că un expert credibil ar oferi „corect și actualizat openssl.cnf dosare”, dar mai degrabă ar putea oferi cel mai bine un proces de evaluare pentru a evalua mai complet cerințele și riscul acceptabil. Deoarece pariați afacerea pe rezultat, niciun expert credibil nu ar face acest lucru în afara protecției un contract. Orice recomandări pe care le primiți ar trebui, aproape prin definiție, să fie de la un expert in credibil. Mult succes.

Comentarii

• Chiar și pentru un intranet pentru resurse interne? S-ar putea să doriți, de asemenea, să indicați că prezentarea este a voastră.
• ” Chiar și pentru un Intranet pentru resurse interne? ” Mai ales pentru intranet, deoarece ‘ s unde apar majoritatea încălcărilor de date. ” Ați putea dori, de asemenea, să indicați că prezentarea este a ta. ” Am crezut că am avut atunci când îmi descriu experiența făcând evaluările, dar am luat în considerare. Am ‘ l-am actualizat.

Urmărește aceste instrucțiuni pentru configurarea unui CA bazat pe Windows . Deoarece eliberați certificate de clienți, rețineți că hash-urile SHA2 nu sunt acceptate pe XP.

Răspunsul simplu este să:

1. Instalați AD
2. Instalați o întreprindere CA pe controlerul de domeniu
3. Editați șablonul de certificat pentru a emite certificate de utilizator final (setați permisiunea ca utilizatorii să se înregistreze automat sau să acceseze o pagină web)
4. Implementați cheia publică a certificatului rădăcină pe toate serverele care validează utilizatorii
5. Dacă utilizatorii sunt pe AD, utilizați GPO pentru a activa înregistrarea automată