Oman varmentajan luominen intranetille

Jos infrastruktuurisi on pieni , suurin osa varmentajan suorittamisen yksityiskohdista (esim. CRL: t ja vastaavat) voidaan todennäköisesti jättää huomioimatta. Sen sijaan sinun tarvitsee vain huolehtia sertifikaattien allekirjoittamisesta.

Siellä on lukuisia työkaluja, jotka hallitsevat tätä prosessia puolestasi. Kirjoitin jopa monta vuotta sitten. Mutta jota suosittelen, jos haluat jotain todella yksinkertaista on easy-rsa OpenVPN-projektista. Se on hyvin ohut kääre OpenSSL-komentorivityökalun ympärille. Jos aiot hallinnoida PALJON varmenteita ja tosiasiallisesti käsitellä kumoamista ja muita asioita, haluat paljon monimutkaisemman ja ominaisuuksiltaan täydellisemmän apuohjelman. Ehdotuksia on jo annettu enemmän kuin tarpeeksi, joten sen sijaan pidän vain kiinni perusasioista, mitä yrität saavuttaa.

Mutta tässä on perusmenettely. Selitän sen OpenSSL: llä , mutta mikä tahansa järjestelmä toimii.

Aloita luomalla ”root” varmentaja – se on itse allekirjoitettu varmenne. Voit tehdä tämän usealla tavalla; tämä on yksi. Teemme meidän 10 vuoden sertifikaatti 2048-bittisellä avaimella.Säädä numeroita tarpeen mukaan. Mainitsit olevasi huolissasi hajautusalgoritmista, joten lisäsin -sha256 varmistaaksesi, että se on allekirjoitettu jollakin hyväksyttävällä tavalla. Salaan avaimen AES-256: lla, mutta se on valinnainen Sinua pyydetään täyttämään varmenteen nimi ja vastaavat; nämä yksityiskohdat eivät ole erityisen tärkeitä juurivarmentajalle.

# 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 

Jos salasit avaimen ensimmäisessä vaiheessa, sinun on annettava salasana käytä sitä toisessa. Tarkista luomasi varmenne varmistaaksesi, että ”Perusrajoitukset” -kohdassa näkyy ”CA: TOSI”. Se on oikeastaan ainoa tärkeä bitti, josta sinun on huolehdittava:

openssl x509 -text < root.cer 

Siisti. OK, anna nyt allekirjoittaa varmenne. Tarvitsemme toisen avaimen ja tällä kertaa pyynnön. Sinulta kysytään uudelleen nimesi ja osoitteesi. Mitä kenttiä täytät ja mitä toimitat, riippuu sinusta ja sovelluksestasi, mutta tärkein kenttä on ”Yleinen nimi”. Siellä annat isäntänimesi tai kirjautumisnimesi tai mitä tämä varmenne todistaa.

# 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 

Huomaa, että tämä luo tiedoston nimeltä root.srl Pidä sarjanumeromme suorina. -CAcreateserial -lippu käskee openssl: tä luomaan tämän tiedoston, joten toimitat sen ensimmäisen allekirjoittamasi pyynnön yhteydessä ja ei koskaan uudelleen. Ja jälleen kerran näet, missä lisätä argumentti -sha256.

Tämä lähestymistapa – kaiken tekeminen manuaalisesti – ei mielestäni ole paras idea. Jos suoritat mittavaa toimintoa , niin luultavasti tarvitset työkalun, joka voi seurata kaikkia varmenteitasi puolestasi.

Sen sijaan esitin sinulle, että haluamasi tulos – varmenteet allekirjoittivat haluamallasi tavalla. ne – ei ole riippuvainen käyttämistäsi työkaluista, vaan pikemminkin niille tarjoamista vaihtoehdoista. Useimmat työkalut voivat tuottaa monenlaisia kokoonpanoja, sekä vahvoja että heikkoja, ja sinun on annettava haluamasi numerot m sopiva. Vanhentuneet oletusarvot ovat kurssilla par.

Kommentit

• On ’ tärkeää huomata, että kun allekirjoitat asiakassertifikaatin, se on vain julkinen -osa. Varmentajan ei pidä lähettää tai luoda yksityistä avainta.
• Voisitko laajentaa vastaustasi välivarmentajan luomiseen? Kiitos.
• @Andr é Välisertifikaatit ovat vain normaaleja varmenteita, joiden basicConstraints = CA:TRUE -asetukset on asetettu. Ei mitään taikaa, vain yksi sertifikaatti.
• @tylerl Dude, rokkaa.
• Tämä vastaus on FANTASTINEN ja hyödyllinen, mutta minun on lisättävä vuoden 2017 päivitys. Chrome ja muut tarvitsevat nyt x509v3 subjectAlternativeName -laajennuksen; muuten he pitävät varmentetta virheellisenä, vaikka järjestelmään olisi asennettu oikein CA-varmenne. Taistelin jonkin aikaa oikean ratkaisun löytämiseksi. Tämä sivu oli minulle korvaamaton ja ratkaisi minulle viimeisen palapelin: cmrg.fifthhorseman.net/wiki/SubjectAltName . IMO, SAN: n lisääminen allekirjoittaessaan, toisin kuin pyynnön yhteydessä, on sekä helpompaa että enemmän kuin julkiset varmentajat todellisuudessa tekevät.

Jos todella haluat olla varmentaja, ota huomioon sen tekemisen turvallisuusvaikutukset.

1. Sisäisen varmenteen luomiseen intranetille käytetyn yksityisen avaimen tulisi kirjaimellisesti lukita tallelokeroon. Ja pääsyä mainittuun kassakaappiin tulisi valvoa fyysisesti.
2. Itse allekirjoitetun juurivarmentajan käyttö pakottaa käyttäjät paitsi luottamaan siihen, että suoritat huolellisuutta avainten turvallisen valvonnan kanssa, myös lisäämään alun perin epäluotettavan juuren voi varmenteketjuunsa.
3. Tämä rikkoo myös OSCP-nidontatoiminnot varmenteketjun ulkoisen todentamisen suhteen, mikä on syy identiteetinhallintapalveluiden olemassaoloon.

Melko harvat väittäisivät oman CA: n hallinnan perustelut, kuten; se on tarkoitettu yrityksen intranetille, jossa osa työpöydän rakennelmistamme sisältää root-juuren tai pienelle määrälle käyttäjiä.

Vaikka se ei ole välttämättä väärin, ja sillä voi olla joitain etuja hylkää varmennusketju, jolle sertifikaattipohjainen henkilöllisyyden hallinta on rakennettu.

Jos päätät ottaa käyttöön oman root-ca: n, varmista, että noudatat samoja suojauskäytäntöjä kuin mitä tahansa muuta root ca -käyttöjärjestelmää. Viimeinen asia, jonka haluaisit tapahtuvan, on se, että joku vaarantaa root-pääkäyttäjääsi käytetyn yksityisen avaimen ja alkaa allekirjoittaa sertifikaatteja verkkourkintakampanjoille asiakkaitasi vastaan.

Tähän on tarjolla useita parhaita käytäntöjä koskevia ohjeita, NIST National Institute for Standards and Technology) on yhteistyöryhmä, joka avustaa erilaisia tietoturva-alan standardeja.

Suositeltu käsittely:
Tarkastus (PDF)
Palautus (PDF)
Julkisen avaimen järjestelmät (PDF)
Sans-instituutti pienemmät PKI-käyttöönotot

Ok, näen päivittämäsi kysymyksesi tarkemmaksi.

Kaksi asiakirja openssl.cnf-tiedoston määrittämiseksi varmentajan erityispiirteille:

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

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

Ymmärrän, että tämä ei välttämättä ole haluamasi vastaus, vaan koska kaikkien ympäristö ja vaatimukset ovat erilaiset, aiot täytyy määritellä varmenteen myöntäjän soveltamisala hyvälle esimerkkikokoonpanolle.

Kommentit

• Siellä ’ s ei ole syytä, miksi oma varmentajasi ’ ei voi tehdä OCSP: tä. Jopa OpenSSL-komentorivi pystyy siihen ja että ’ s noin alimmasta mahdollisesta palkista.
• openssl-linkkejä on nyt 404

Siellä ei ole tapa tehdä tätä yksinkertaisesti. on joitain työkaluja, joiden avulla pääset helposti alkuun.

kuten:

• XCA
• EJBCA
• openssl

yksikään niistä ei ole täysi PKI lukuun ottamatta mahdollisesti EJBCA: ta, mutta se ei ole triviaalia asentaa.

• XCA on pieni käyttöliittymätyökalu, jolla saadaan graafinen käyttöliittymä varmenteiden luomiseen, allekirjoittamiseen ja peruuttamiseen.
• EJBCA- tai Enterprise Java Beans -sertifikaattiviranomainen on JBOSS / Jetty Webapp -sovellus, joka pystyy suorittamaan koko yrityksen PKI-infrastruktuurin.
• openssl on komentokomennon perustyökalu. se voi tehdä kaikki varmentajan offline-bitit, mutta mitään tarkistusta (kättelyssä). voit tehdä omat OCSP-todentajat sen avulla, mutta sinun on tehtävä sille ”online” -koodi itse.

Jos etsit vain oikein, openssl config. XCA voi auttaa sinua luomaan ne. (sillä on openssl-määritysten vientiominaisuus

Kommentit

• EJBCA: lla on nyt virtuaalikoneen kuva, jota voit käyttää. Muuten ” ei ole triviaalia ” -asetuksen määrittämiselle. Tätä voidaan pitää aliarvostuksena. Periaatteessa valtava komentosarja ant yrittää määrittää ( JBoss) sovelluspalvelin, joka voi (ja minun tapauksessani hajoaa ) hajota.
• virtuaalikoneen kuva on tai arviointitarkoitus, joten en suosittele sitä tuotantopalvelimelle.
• Voin tutkia XCA: ta. EJBCA ei ehdottomasti ole ’ vaihtoehto – verkkoliitäntä lisää turhaa hyökkäyspintaa ja sitä on vaikea asentaa. Pidän ehdottomasti parempana vain openssl.
• @Andr é EJBCA: n osalta sitä voidaan käyttää myös komentoriviltä, joten voitit ’ t on paljastettava verkkokäyttöliittymä. Mutta se ’ on yritystason asia ja todennäköisesti ylittää tarkoituksesi es (ja sanon tämän henkilönä, joka ansaitsee elantonsa työskentelemällä sen kanssa).

Joillekin hyvä tausta, katso esitykseni Kuinka rakentaa ja käyttää omaa keskinkertaisuuden varmenteiden hallintakeskusta . Esityksen ydin on se, että kaikkein vaadituin asia ei ole luettelo suoritettavista komennoista, vaan pikemminkin syvällinen ymmärrys kaikista kaupallisen varmentajan toimintaan käytetyistä erilaisista ohjaimista, niiden yhteisvaikutuksesta, tarkan vaikutuksen poistamisesta yksi niistä, useiden niistä poistamisen kumulatiivinen vaikutus ja vähennetyn turvallisuuden kompensoimiseksi tarvittavat lieventävät hallintatoimet.

Siksi ei ole ”yksinkertaista vastausta yksinkertaisen varmentajan perustamisesta”. menet koko ISO-reitin alkaen avaimen allekirjoittajaryhmästä, ilmavälillä olevista ja holvatuista päällekkäisistä varmenteista, useista väli-allekirjoittajista, kumoamispalvelimista jne. jne., tai muuten sinun on suunniteltava kompromissi ainutlaatuisen kustannus-hyötyanalyysin ja riskin perusteella Profiili, jonka yritys on valmis hyväksymään. Kuka tahansa, jolla on riittävästi taitoa ja kokemusta arvioinnin tekemiseksi määritelmän mukaan, ei tarvitse huijauslehteä. He voivat jäsentää oikean komentosyntaksin perustuen syvälliseen ymmärrykseen suoritettavasta liiketoiminnasta ja tietoturva-alkeista, joita käytetään tämän vaatimuksen toteuttamiseen.

Esityksessä on tarinoita kauppojen todellisesta sitoutumisesta, jotka menivät tällä tiellä ja tekivät sen hirvittävän väärin. Joissakin tapauksissa arvioni ilmoitti, että mikään, mitä voin tehdä väliohjelmistoturvallesi, ei voi voittaa sisäisen varmentajan luontaisia heikkouksia. Kenen tahansa Yhdysvalloissa tulisi ymmärtää, että hän todennäköisesti ostaa palveluja ainakin yhdeltä toimittajalta, johon esitys viittaa. Nämä ovat pankkeja, luottoyhdistyksiä, sairausvakuutusyhtiöitä, vähittäiskauppiaita ja paljon muuta.

Koska suositukset ovat ”oikeita”, vastaajan on tehtävä suuria oletuksia hyväksyttävistä riskiprofiileistasi ja voit tehdä suuria oletuksia siitä, missä määrin sinun ja heidän riskisi ajatuksesi ovat linjassa synkronoituna jo ehdotus on riskialtista. Useimmissa tällaisissa tapauksissa tarjottujen opetusohjelmien soveltuvuuden arviointi liittyy enemmän esitykseen kuin heidän menettelytapojensa noudattamisesta johtuvaan tehokkaaseen turvallisuustasoon. Jos se on hyvin järjestetty ja selkeästi muotoiltu, sillä on paljon enemmän kuin sen tehokkuus. Valitsemme kanonisen huijauslehden, joka näyttää meille parhaiten.

Näistä syistä en usko, että uskottava asiantuntija tarjoaisi ”oikean ja ajantasaisen openssl.cnf -tiedostot”, mutta pikemminkin saattaisi tarjota parhaimmillaan arviointiprosessin vaatimusten ja hyväksyttävän riskin arvioimiseksi täydellisemmin. Koska lyöt vetoa yritykselläsi tuloksesta, mikään uskottava asiantuntija ei tekisi tätä ulkopuolisten tahojen suojan ulkopuolella. sopimuksen. Kaikkien saamiesi suositusten on melkein määritelmän mukaan oltava uskottavan in asiantuntijan edustajilta. Onnea.

Kommentit

• Jopa sisäisten resurssien intranetissä? Haluat myös ilmoittaa, että esitys on oma.
• ” Jopa sisäisten resurssien intranet? ” Erityisesti intranetille, koska ’ s missä useimmat tietorikkomukset tapahtuvat. ” Haluat ehkä myös ilmoittaa että esitys on oma. ” Luulin, että minulla oli kuvaillessani kokemuksiani arvioiden tekemisestä, mutta otin sen huomioon. Olen ’ päivittänyt sen.

Seuraa näitä ohjeet Windows-pohjaisen varmentajan määrittämiseen . Koska annat asiakassertifikaatteja, muista, että SHA2-tiivisteitä ei tueta XP: ssä.

Yksinkertainen vastaus on:

1. Asenna AD
2. Asenna Enterprise-varmentaja toimialueen ohjaimeen
3. Muokkaa varmentemallia loppukäyttäjän varmenteiden myöntämiseksi (aseta käyttäjille lupa rekisteröityä itse tai mennä verkkosivulle)
4. Ota juurivarmenteen julkinen avain käyttöön kaikissa palvelimissa, jotka validoivat käyttäjiä
5. Jos käyttäjät ovat AD: ssä, ota automaattinen rekisteröinti käyttöön GPO: n avulla