Poate MS Certificate Services să fie subordonat unei CA create cu OpenSSL? (Administrarea sistemului, Certificat Ssl, Windows, Openssl, Autoritate De Certificare)

Zoredache a intrebat.

Doresc să configurez o autoritate de certificare a întreprinderii pentru domeniul meu. Ca să pot emite certificate pentru diverse scopuri. Aș dori să urmez cea mai bună practică de a avea o CA offline ca rădăcină și să configurez CA-ul meu de întreprindere ca un subordonat. Dar mi se pare o prostie să licențiez o copie completă a Windows pentru această sarcină.

Ceea ce sper să pot face este să instalez o distribuție live pe un disc flash USB, apoi să instalez openssl și să îmi configurez AC pe unitatea flash. Când sunt gata să construiesc cheia/certificatul root, voi deconecta computerul de la rețea și apoi nu voi mai folosi niciodată acel disc USB pe un computer conectat la rețea.

Voi putea să semnez și să creez în mod corespunzător un certificat de CA subordonat pentru o CA de întreprindere Windows, care să fie utilizabil. Ce opțiuni trebuie să folosesc în OpenSSL pentru a crea CA și a semna corect certificatul CA subordonat.

Am încercat să caut pe internet, iar acest a fost singurul lucru pe care l-am putut găsi pe această temă. Dar este anterior anului 2008 și nu sunt pe deplin sigur că persoana respectivă a avut succes.

Comentarii

  • Pentru a fi clar, Instrumentul nu trebuie să fie neapărat OpenSSL, dar nu vreau să conduc o CA uriașă precum EJBCA. Caut o CA foarte ușoară, care poate fi rulată într-un mediu livecd/liveusb. –  > Por Zoredache.
2 răspunsuri
Shane Madden

Da, funcționează foarte bine; o autoritate de certificare Windows nu are nicio reținere în a rula ca subordonată unei rădăcini non-Windows.

Testat cu un root OpenSSL și un Windows 2008 R2 subordonat în modul Enterprise.


Câteva lucruri pentru a juca frumos cu ceea ce se așteaptă MS CA în configurația OpenSSL:

  • Locațiile valide AIA și CDP trebuie să se aplice certificatului root, în secțiunea configurată de către x509_extensions a proprietății [req] secțiune pentru rădăcina auto-semnată. Ceva de genul acesta:

    authorityInfoAccess = caIssuers;URI:http://test-rootca.test.local/root.pem
    crlDistributionPoints = URI:http://test-rootca.test.local/root.crl
    
  • O anumită configurație OpenSSL probabil că nu permite CA-uri subordonate în mod implicit. Schimbați acest lucru pentru cererile semnate (asigurați-vă că acest lucru nu este în vigoare pentru cererile care nu ar trebui să fie CA-uri, desigur). Acest lucru se va întâmpla în secțiunea configurată de către x509_extensions a proprietății [ca] secțiune:

    basicConstraints=CA:TRUE
    certificatePolicies=2.5.29.32.0
    

Deci, vom face o CA pentru a testa.

Faceți rădăcina dvs:

openssl req -new -x509 -keyout /etc/ssl/private/root.key -out /etc/ssl/certs/root.pem -nodes -extensions v3_ca

Manipulați configurația și creați fișierele și directoarele necesare în secțiunea [ca] din configurația OpenSSL.

Totul este pregătit pentru a pune în funcțiune partea Microsoft; creați o CA subordonată Windows cu semnare manuală.

Încărcați cererea de certificat către serverul OpenSSL. Dacă tot ați ajuns acolo, descărcați certificatul rădăcină. Importați-l în magazinul de rădăcini de încredere – al computerului, nu al utilizatorului dumneavoastră!

Eliberați certificatul subordonat:

openssl ca -in test-subca.req
(you might need to specify a permissive policy manually with -policy, check your config)

Dacă nu a funcționat, probabil că AC-ul dvs. are o problemă cu configurația – noul director certs, fișierul index, fișierul serial etc. Verificați mesajul de eroare.

Dacă a mers, atunci asta este. Dacă nu a mers, faceți un CRL și puneți-l în CDP-ul pe care l-ați configurat mai sus; eu doar am instalat Apache și l-am blocat în webroot:

openssl ca -gencrl -out /var/www/root.crl

Și puneți certificatul dvs. în locația AIA, dacă nu este deja:

cp /etc/ssl/certs/root.pem /var/www/root.pem

Descărcați certificatul subordonat nou emis și instalați-l în CA cu ajutorul snap-in-ului MMC Certification Authority. Se va plânge de orice problemă de încredere sau de validare, dar nu are nicio obiecție morală să o ia.

Rezultatul final; o CA Windows funcțională, fără să se plângă de la snap-in-ul Enterprise PKI, cu un semn distinctiv OpenSSL Generated Certificate în atribute.

dunxd

Înțeleg unde vreți să ajungeți, dar nu cred că OpenSSL este chiar instrumentul potrivit pentru această sarcină. Poate doriți să vă uitați la Proiecte de autoritate de certificare cu sursă deschisă cum ar fi EJBCA care se concentrează mai mult pe această funcționalitate decât OpenSSL și au documentație specifică pe care o puteți utiliza.

Nu văd niciun motiv pentru care acest concept nu ar funcționa, deoarece tot ceea ce faceți este să semnați certificatul autorității de certificare subordonate. Dacă ați plăti o autoritate de certificare publică pentru a face acest lucru în locul dumneavoastră, nu ați ști sau nu v-ar interesa neapărat ce tip de server folosește.

Tot ceea ce trebuie să vă intereseze este:

  • puteți semna certificatul din CSR-ul generat de subordonatul dvs.
  • rezultatul poate fi instalat chiar pe subordonat
  • aveți un certificat de semnare rădăcină care poate fi instalat ca fiind de încredere pe orice client pe care îl vizați.
  • puteți genera o listă de revocare care să fie servită undeva

Nu pot spune că am făcut acest lucru, dar sunt sigur că dacă urmați documentația pentru generarea unui CSR de la o cutie Windows, apoi urmați documentația CA pentru generarea unui certificat .p7k dintr-un CSR, atunci ar trebui să fie bine.

Apropo – v-aș recomanda să vă creați CA-ul ca o mașină virtuală pentru un hipervizor popular, cum ar fi Hyper-V sau VMware, mai degrabă decât un disc de boot, asigurați-vă că îl stocați în siguranță undeva unde succesorul dvs. îl poate găsi și că îl porniți periodic offline pentru a vă asigura că funcționează sau că îl transferați pe un nou suport/tehnologie. O AC rădăcină poate avea o durată de viață de 10 sau 20 de ani…

Comentarii

  • +1 OpenSSL nu este cel mai bun instrument pentru crearea unei CA, dar funcționează în general. Nu am emis un certificat sub-CA pentru un Windows Enterprise CA, dar nu-mi pot imagina de ce nu ar funcționa (deși MS a comis în trecut acte anticoncurențiale mai grave). Un mare +1 pentru CA ca VM. Păstrarea unei a doua copii a certificatului rădăcină este o idee bună (Base64 pe hârtie este foarte durabil și ușor de păstrat într-un seif/cutie de depozit/etc) –  > Por Chris S.
  • Am fost destul de mulțumit de mine însumi când mi-am dat seama că pot configura o VM fără NIC-uri și să folosesc doar o unitate de dischetă virtuală pentru a obține CSR-uri și certificate semnate. Sneakernet a renăscut cu o strălucire virtuală a secolului 21! –  > Por dunxd.