Opprette min egen CA for et intranett

Hvis infrastrukturen din er liten , mye av detaljene i å kjøre en CA (f.eks. CRL og lignende) kan sannsynligvis ignoreres. I stedet er alt du virkelig trenger å bekymre deg for å signere sertifikater.

Det er mange verktøy der ute som vil håndtere denne prosessen for deg. Jeg skrev til og med en for mange år siden. Men den jeg anbefaler hvis du vil at noe veldig enkelt er easy-rsa fra OpenVPN-prosjektet. Det er en veldig tynn innpakning rundt OpenSSL-kommandolinjeverktøyet. Hvis du skal administrere MYE sertifikater og faktisk har å gjøre med tilbakekalling og sånt, vil du ha et mye mer komplekst og funksjonelt komplett verktøy. Det er mer enn nok forslag som allerede er gitt, så i stedet vil jeg bare holde meg til det grunnleggende om hva du prøver å oppnå.

Men her er den grunnleggende prosedyren. Jeg forklarer det med OpenSSL , men ethvert system vil gjøre det.

Start med å opprette «root» CA – det vil være et selvsignert sertifikat. Det er flere måter å gjøre dette på. Dette er en. Vi vil lage vårt 10-års cert med 2048-bit nøkkel.Juster tallene etter behov. Du nevnte at du var bekymret for hashingalgoritme, så jeg la til -sha256 for å sikre at den er signert med noe akseptabelt. Jeg krypterer nøkkelen med AES-256, men det er valgfritt . Du blir bedt om å fylle ut sertifikatnavnet og slikt. disse detaljene er ikke spesielt viktige for en rot-CA.

# 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 

Hvis du krypterte nøkkelen i første trinn, må du oppgi passordet til bruk den i det andre. Sjekk det genererte sertifikatet ditt for å forsikre deg om at du ser «CA: TRUE» under «Grunnleggende begrensninger». Det er egentlig den eneste viktige biten du trenger å bekymre deg for:

openssl x509 -text < root.cer 

Kult. OK, la oss nå signere et sertifikat. Vi trenger en ny nøkkel og denne gangen en forespørsel. Du blir spurt om navnet ditt og adressen din igjen. Hvilke felt du fyller ut og hva du leverer, er opp til deg og søknaden din, men feltet som betyr mest er «Common Name». Det er der du oppgir vertsnavnet eller påloggingsnavnet ditt eller hva dette sertifikatet skal attestere.

# 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 

Merk at dette oppretter en fil som heter root.srl til hold serienumrene våre rett. -CAcreateserial -flagget forteller openssl om å opprette denne filen, så du leverer den for den første forespørselen du signerer og aldri mer. Og nok en gang kan du se hvor å legge til argumentet -sha256.

Denne tilnærmingen – å gjøre alt manuelt – er etter min mening ikke den beste ideen. Hvis du kjører en betydelig operasjon , vil du sannsynligvis ha et verktøy som kan holde oversikt over alle sertifikatene dine for deg.

I stedet var poenget mitt her å vise deg at utdataene du ønsker – sertifikatene signerte slik du vil dem – er ikke avhengig av verktøyene du bruker, men heller alternativene du gir til disse verktøyene. De fleste verktøy kan levere et bredt utvalg av konfigurasjoner, både sterke og svake, og det er opp til deg å oppgi tallene du dee m passende. Utdaterte standardverdier er like for kurset.

Kommentarer

• Det er ‘ det er viktig å merke seg at når du signerer et klientsertifikat, det er bare offentlig del. Ingen privat nøkkel skal overføres eller genereres av CA.
• Kan du utvide svaret ditt når du oppretter et mellomliggende CA-sertifikat? Takk.
• @Andr é Mellomliggende certs er bare normale certs med basicConstraints = CA:TRUE satt i sine utvidede attributter. Ingenting magisk, bare nok et sertifikat.
• @tylerl Dude, du rocker.
• Dette svaret er FANTASTISK og var veldig nyttig, men jeg har en oppdatering fra 2017 å legge til. Chrome og andre krever nå x509v3 subjectAlternativeName utvidelsen; Ellers anser de sertifikatet som ugyldig, selv med et CA-rotsertifikat riktig installert på systemet. Jeg slet en stund med å finne den rette løsningen. Denne siden var uvurderlig for meg, og løste den siste brikken i puslespillet for meg: cmrg.fifthhorseman.net/wiki/SubjectAltName . IMO, å legge til SAN når du signerer, i motsetning til når du ber om det, er både enklere og mer som det offentlige CAer faktisk gjør.

Der er ingen måte å gjøre dette rett og slett. det er noen verktøy som kan hjelpe deg med å komme i gang enkelt.

som:

• XCA
• EJBCA
• openssl

ingen av dem er en full PKI bortsett fra muligens EJBCA, men det er ikke trivielt å sette opp.

• XCA er et lite frontend-verktøy for å få et grafisk grensesnitt for å generere, signere og tilbakekalle sertifikater.
• EJBCA eller Enterprise Java Beans Certificate Authority er en JBOSS / Jetty Webapp som kan gjøre hele PKI-infrastrukturen for en bedrift.
• openssl er det grunnleggende kommandolinjeverktøyet. det kan gjøre alle de frakoblede bitene i en CA, men ingen av bekreftelsen (utenom boksen). du kan lage dine egne OCSP Verifiers med det, men du må lage «online» koden for det selv.

Hvis alt du søker er riktig openssl-konfigurasjon. XCA kan hjelpe deg med å generere dem. (den har en openssl-konfigurasjonseksportfunksjon

Kommentarer

• EJBCA har nå et VM-bilde du kan bruke. Ellers » ikke trivielt å sette opp » kan betraktes som en underdrivelse. Det er i utgangspunktet et stort ant skript som prøver å konfigurere ( JBoss) applikasjonsserver som kan (og i mitt tilfelle vil ) brytes ned.
• VM-bildet er eller evalueringsformål, så jeg vil ikke anbefale det for en produksjonsserver.
• Jeg kan se på XCA. EJBCA er definitivt ikke ‘ t et alternativ – et webgrensesnitt legger til en unødvendig angrepsflate og er vanskeligere å sette opp. Jeg foretrekker definitivt å bruke bare openssl skjønt.
• @Andr é når det gjelder EJBCA, kan den også brukes fra kommandolinjen, så du vant ‘ t må avsløre nettgrensesnittet. Men det ‘ er en bedriftsnivå og sannsynligvis overkill for ditt formål es (og jeg sier dette som noen som lever av å jobbe med det).

For noen god bakgrunn, vennligst se presentasjonen min Slik bygger du og driver ditt eget sertifikatadministrasjonssenter for middelmådighet . Kjernen i presentasjonen er at det mest påkrevde ikke er en liste over kommandoene som skal kjøres, men snarere en dyp forståelse av alle de forskjellige kontrollene som går til drift av en kommersiell CA, hvordan de samhandler sammen, den nøyaktige virkningen av å fjerne en av dem, den kumulative effekten av å fjerne flere av dem, og de avbøtende kontrollene som er nødvendige for å kompensere for redusert sikkerhet.

Dette er grunnen til at det ikke er noe «kanonisk svar om å sette opp en enkel CA.» du går hele ISO-ruten, og starter med en nøkkelsigneringsfest, luftgappede og hvelvede dupliserte rotserter, flere mellomliggende signatorer, tilbakekallingsservere osv., etc., ellers må du lage et kompromiss basert på den unike kostnad / nytte og risiko profilere virksomheten er villig til å akseptere. Enhver med tilstrekkelig dyktighet og erfaring til å gjøre denne vurderingen per definisjon trenger ikke jukselaget. De kan analysere riktig kommandosyntaks basert på en dyp forståelse av forretningsfunksjonen som skal oppnås og sikkerhetsprimitivene som brukes til å implementere dette kravet.

I presentasjonen er historier fra ekte engasjementer fra butikker som gikk ned denne veien og fikk det veldig galt. I noen tilfeller rapporterte vurderingen min at absolutt ingenting jeg kan gjøre med mellomvaresikkerheten din muligens kan overvinne de iboende svakhetene til den interne CA. Alle i USA bør innse at de sannsynligvis kjøper tjenester fra minst en av leverandørene som presentasjonen refererer til. Dette er banker, kredittforeninger, helseforsikringsselskaper, forhandlere og mer.

Siden for at anbefalingene skal være «riktige» krever svareren å gjøre store forutsetninger om dine akseptable risikoprofiler, og at du skal legge store forutsetninger om i hvilken grad dine og deres ideer om risiko er tilpasset og i synkronisering er selve forslaget risikabelt. I de fleste slike tilfeller har vurderingen av egnetheten til opplæringen gitt mer å gjøre med presentasjonen enn med det effektive sikkerhetsnivået som følge av prosedyrene. Hvis det er godt organisert og tydelig artikulert, betyr dette MYE mer enn om det er effektivt. Vi velger det kanoniske juksearket som ser best ut for oss.

Av disse grunnene tror jeg ikke en troverdig ekspert vil gi «riktig og oppdatert openssl.cnf filer,» men kan i beste fall gi en evalueringsprosess for å vurdere kravene og akseptabel risiko mer fullstendig. Siden du satser virksomheten på resultatet, vil ingen troverdig ekspert gjøre dette utenfor beskyttelsen av En kontrakt. Eventuelle anbefalinger du får, må nesten per definisjon være fra en in pålitelig ekspert. Lykke til.

Kommentarer

• Selv for et intranett for interne ressurser? Du vil kanskje også indikere at presentasjonen er din egen.
• » Selv for en intranett for interne ressurser? » Spesielt for intranettet siden ‘ s der de fleste datainnbrudd forekommer. » Det kan også være lurt å indikere at presentasjonen er din egen. » Jeg trodde jeg hadde da jeg beskrev min erfaring med å gjøre vurderingene, men poeng tatt. Jeg ‘ har oppdatert den.

Følg disse instruksjoner for å konfigurere en Windows Based CA . Siden du utsteder klientsertifikater, må du være oppmerksom på at SHA2-hashes ikke støttes på XP.

Det enkle svaret er å:

1. Installer AD
2. Installer en bedrifts-CA på domenekontrolleren
3. Rediger sertifikatmalen for å utstede sluttbruker-sertifikater (angi tillatelse for brukere til å registrere seg selv, eller gå til en webside)
4. Distribuere den offentlige nøkkelen til rotsertifikatet til alle servere som validerer brukere
5. Hvis brukerne er på AD, bruk GPO for å aktivere automatisk påmelding