Oprettelse af min egen CA for et intranet

Hvis din infrastruktur er lille , mange af detaljerne i at køre en CA (f.eks. CRLer og lignende) kan sandsynligvis ignoreres. I stedet er alt hvad du virkelig skal bekymre dig om at underskrive certifikater.

Der er et væld af værktøjer derude, der styrer denne proces for dig. Jeg skrev endda en for mange år siden. Men den jeg anbefaler, hvis du vil have noget virkelig simpelt er easy-rsa fra OpenVPN-projektet. Det er en meget tynd indpakning omkring OpenSSL-kommandolinjeværktøjet. Hvis du vil administrere MEGET med certifikater og faktisk beskæftige dig med tilbagekaldelse og lignende, vil du gerne have et meget mere komplekst og komplet hjælpeprogram. Der er allerede leveret mere end nok forslag, så i stedet holder jeg bare med det grundlæggende i det, du prøver at udføre.

Men her er den grundlæggende procedure. Jeg forklarer det med OpenSSL , men ethvert system gør det.

Start med at oprette din “root” CA – det vil være et selvsigneret certifikat. Der er flere måder at gøre dette på. Dette er en. Vi laver vores et 10-årigt certifikat med en 2048-bit nøgle.Tilpas tallene efter behov. Du nævnte, at du var bekymret for hashingalgoritme, så jeg tilføjede -sha256 for at sikre, at den er underskrevet med noget acceptabelt. Jeg krypterer nøglen ved hjælp af AES-256, men det er valgfrit . Du bliver bedt om at udfylde certifikatnavnet og sådan; disse detaljer er ikke særlig vigtige for en root 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 krypterede nøglen i første trin, skal du give adgangskoden til brug det i det andet. Kontroller dit genererede certifikat for at sikre dig, at du under “Grundlæggende begrænsninger” ser “CA: SAND”. Det er virkelig den eneste vigtige bit, du skal bekymre dig om:

openssl x509 -text < root.cer 

Cool. OK, lad os nu underskrive et certifikat. Vi har brug for en ny nøgle, og denne gang en anmodning. Du bliver igen spurgt om dit navn og din adresse. Hvilke felter du udfylder, og hvad du leverer, er op til dig og din ansøgning, men det felt, der betyder mest, er “Almindeligt navn”. Det er her, du angiver dit værtsnavn eller loginnavn eller hvad dette certifikat 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 

Bemærk at dette opretter en fil kaldet root.srl til hold vores serienumre lige. -CAcreateserial flag fortæller openssl om at oprette denne fil, så du leverer den til den første anmodning, du underskriver, og derefter aldrig igen. Og igen kan du se, hvor at tilføje argumentet -sha256.

Denne fremgangsmåde – at gøre alt manuelt – er efter min mening ikke den bedste idé. Hvis du kører en betydelig operation , så vil du sandsynligvis have et værktøj, der kan holde styr på alle dine certifikater til dig.

I stedet var min pointe her at vise dig, at den ønskede output – certifikaterne blev underskrevet, som du ønsker dem – afhænger ikke af de værktøjer, du bruger, men snarere de muligheder, du giver til disse værktøjer. De fleste værktøjer kan sende en bred vifte af konfigurationer, både stærke og svage, og det er op til dig at levere de numre, du dee m passende. Forældede standardindstillinger er par for kurset.

Kommentarer

• Det ‘ er vigtigt at bemærke, at når du underskriver et klientcertifikat, det er kun den offentlige del. Ingen privat nøgle skal transmitteres eller genereres af CA.
• Kan du udvide dit svar om oprettelse af et mellemliggende CA-certifikat? Tak.
• @Andr é Mellemliggende certs er bare normale certs med basicConstraints = CA:TRUE indstillet i deres udvidede attributter. Intet magisk, bare endnu et certifikat.
• @tylerl Dude, du rocker.
• Dette svar er FANTASTISK og var super nyttigt, men jeg har en opdatering fra 2017 at tilføje. Chrome og andre kræver nu udvidelsen x509v3 subjectAlternativeName; Ellers betragter de certifikatet som ugyldigt, selv med et CA-rodcertifikat korrekt installeret på systemet. Jeg kæmpede i nogen tid med at finde den rigtige løsning. Denne side var uvurderlig for mig og løste det sidste stykke af puslespillet for mig: cmrg.fifthhorseman.net/wiki/SubjectAltName . IMO, tilføjelse af SAN, når der underskrives, i modsætning til når der anmodes om, er både nemmere og mere som det, de offentlige CAer faktisk gør. = “answer”>

  Hvis du virkelig ønsker at være CA, skal du være opmærksom på sikkerhedsimplikationerne ved at gøre det.

  1. Den private nøgle, der bruges til at generere root CA til dit intranet, skal bogstaveligt talt være være låst i et pengeskab. Og adgang til nævnte pengeskab skal overvåges fysisk.
  2. Brug af en selvunderskrevet root CA tvinger dine brugere til ikke kun at stole på, at du udfører en omhyggelig omhu med sikker beskyttelse af nøgler, men også at indsætte en oprindeligt ikke-betroet rod kan ind i deres certifikatkæde.
  3. Dette bryder også OSCP-hæftefunktionalitet med hensyn til ekstern verifikation af certifikatkæden, hvilket er grunden til, at identitetsstyringstjenester eksisterer i første omgang.

  En hel del vil argumentere for ræsonnementet bag styring af din egen CA som f.eks. det er til et virksomhedsintranet, hvor en del af vores desktop-build inkluderer root ca, eller det er for et lille antal brugere.

  Selvom det ikke nødvendigvis er forkert at gøre det og muligvis har nogle fordele, gør det neger verifikationskæden, som certifikatbaseret identitetsstyring blev bygget til.

  Hvis du beslutter dig for at implementere din egen root ca, skal du bare sørge for at følge de samme sikkerhedsmetoder som enhver anden root CA bruger. den sidste ting, du gerne vil have, er, at nogen kompromitterer den private nøgle, der bruges til din root ca, og begynder at underskrive certifikater til phishing-kampagner mod dine kunder.

  Der er masser af vejledninger til bedste praksis til rådighed for dette, NIST ( nationale institut for standarder og teknologi) er en samarbejdsgruppe, der bistår med forskellige standarder inden for computersikkerhedsemner.

  Anbefalet læsning:
  Auditing (PDF)
  Disaster Recovery (PDF)
  Public Key Systems (PDF)
  Sans institut angående mindre PKI-implementeringer

  Ok, jeg kan se, at du opdaterede dit spørgsmål til at være mere specifikt.

  To dokumenter til konfiguration af din openssl.cnf-fil til CA-specifikationer:

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

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

  Jeg er klar over, at dette måske ikke er det svar, du ønsker, men fordi alles miljø og krav er forskellige, skal du er nødt til at definere et omfang til din CA-implementering for et godt eksempel på konfiguration.

  Kommentarer

  • Der ‘ ingen grund til, at din egen CA ikke kan ‘ ikke gøre OCSP. Selv OpenSSL-kommandolinje kan gøre det, og at ‘ s om den lavest mulige bjælke.
  • openssl-links er nu 404

Der er ingen måde at gøre dette på. der er nogle værktøjer, der kan hjælpe dig med let at komme i gang.

ligesom:

• XCA
• EJBCA
• openssl

ingen af dem er en fuld PKI bortset fra muligvis EJBCA, men det er ikke trivielt at opsætte.

• XCA er et lille frontend-værktøj til at få en grafisk grænseflade til at generere, underskrive og tilbagekalde certifikater.
• EJBCA eller Enterprise Java Beans Certificate Authority er en JBOSS / Jetty Webapp, der kan udføre den fulde PKI-infrastruktur for en virksomhed.
• openssl er det grundlæggende kommandolinjeværktøj. det kan gøre alle offline bits i en CA, men ingen af verifikationen (ud af boksen). du kan lave dine egne OCSP-verifikatorer med det, men du skal selv oprette “online” -koden til det.

Hvis alt hvad du søger er korrekt openssl-konfiguration. XCA kan hjælpe dig med at generere dem. (den har en openssl-konfigurationseksportfunktion

Kommentarer

• EJBCA har nu et VM-billede, du kan bruge. Ellers ” ikke trivielt ved opsætning ” kan betragtes som en underdrivelse. Det er grundlæggende et stort ant script, der forsøger at konfigurere ( JBoss) applikationsserver, der kan (og i mit tilfælde vil ) nedbrydes.
• VM-billedet er eller evalueringsformål, så jeg vil ikke anbefale det til en produktionsserver.
• Jeg kan se på XCA. EJBCA er bestemt ikke ‘ t en mulighed – en webgrænseflade tilføjer en unødvendig angrebsflade og er sværere at konfigurere. Jeg foretrækker bestemt at bruge bare openssl dog.
• @Andr é hvad angår EJBCA, kan det også bruges fra kommandolinjen, så du vandt ‘ t bliver nødt til at eksponere webgrænsefladen. Men det ‘ er en ting på virksomhedsniveau og sandsynligvis overdreven til dit formål es (og jeg siger dette som en, der lever af at arbejde med det).

For nogle god baggrund, se min præsentation Sådan opbygges og drives dit eget certifikatstyringscenter for middelmådighed . Kernen i præsentationen er, at det mest krævede ikke er en liste over kommandoer, der skal køres, men snarere en dyb forståelse af alle de forskellige kontroller, der går i drift af en kommerciel CA, hvordan de interagerer sammen, den nøjagtige virkning af at fjerne en af dem, den kumulative virkning af at fjerne flere af dem og de afbødende kontroller, der er nødvendige for at kompensere for den reducerede sikkerhed.

Dette er grunden til, at der ikke er noget “kanonisk svar om oprettelse af en simpel CA.” du går hele ISO-ruten, startende med en nøglesigneringspart, luftgappede og hvælvede duplikerede rodcerter, flere mellemliggende underskrivere, tilbagekaldelsesservere osv. osv., ellers skal du udarbejde noget kompromis baseret på den unikke omkostning / fordel og risiko profilere virksomheden er villig til at acceptere. Enhver med tilstrækkelig dygtighed og erfaring til at foretage denne evaluering pr. definition behøver ikke snydearket. De kan analysere den korrekte kommandosyntaks baseret på en dyb forståelse af den forretningsfunktion, der skal udføres, og de sikkerhedsprimitiver, der bruges til at implementere dette krav.

I præsentationen er historier fra ægte engagement fra butikker, der gik ned ad denne vej og fik det forfærdeligt forkert. I nogle tilfælde rapporterede min vurdering, at absolut intet, jeg kan gøre med din middlewaresikkerhed, muligvis kan overvinde de iboende svagheder ved den interne CA. Enhver i USA bør indse, at de sandsynligvis køber tjenester fra mindst en af de leverandører, som præsentationen henviser til. Disse er banker, kreditforeninger, sundhedsforsikringsselskaber, detailhandlere og mere.

Da for at anbefalingerne skal være “korrekte” kræver svareren at antage store antagelser om dine acceptable risikoprofiler, og at du fremsætter store antagelser om, i hvor høj grad dine og deres idéer om risiko er tilpasset og i synkronisering er selve forslaget risikabelt. I de fleste af disse tilfælde har vurderingen af egnetheden af de øvede tutorials mere at gøre med præsentationen end med det effektive sikkerhedsniveau som følge af at følge deres procedurer. Hvis det er velorganiseret og tydeligt formuleret, betyder det meget mere, end om det er effektivt. Vi vælger det kanoniske snydeark, der ser bedst ud for os.

Af disse grunde tror jeg ikke, at en troværdig ekspert ville give “korrekt og opdateret openssl.cnf filer”, men kan i bedste fald i bedste fald give en evalueringsproces for at vurdere kravene og den acceptable risiko mere fuldstændigt. Da du satser virksomheden på resultatet, ville ingen troværdig ekspert gøre dette uden for en kontrakt. Alle anbefalinger, du får, skulle næsten pr. definition være fra en in troværdig ekspert. Held og lykke.

Kommentarer

• Selv for et intranet til interne ressourcer? Du vil måske også gerne angive, at præsentationen er din egen.
• ” Selv for en intranet til interne ressourcer? ” Særligt til intranettet, da ‘ s hvor de fleste databrud forekommer. ” Du vil muligvis også angive at præsentationen er din egen. ” Jeg troede, jeg havde det, da jeg beskrev min erfaring med at foretage vurderingerne, men dog taget i betragtning. Jeg ‘ har opdateret det.

Følg disse instruktioner til konfiguration af en Windows-baseret CA . Da du udsteder klientcertifikater, skal du være opmærksom på, at SHA2-hashes ikke understøttes på XP.

Det enkle svar er at:

1. Installer AD
2. Installer en virksomheds-CA på domænecontrolleren
3. Rediger certifikatskabelonen for at udstede slutbrugercertifikater (indstil tilladelsen til brugerne til at tilmelde sig selv, eller gå til en webside)
4. Implementere den offentlige nøgle til rodcertifikatet til alle servere, der validerer brugere
5. Hvis brugerne er på AD, skal du bruge GPO til at aktivere automatisk tilmelding