Mijn eigen CA aanmaken voor een intranet

Als uw infrastructuur klein is , veel van de details van het uitvoeren van een CA (bijv. CRLs en dergelijke) kunnen waarschijnlijk worden genegeerd. In plaats daarvan hoef je je alleen maar zorgen te maken over het ondertekenen van certificaten.

Er is een groot aantal tools beschikbaar die dit proces voor je zullen beheren. Ik heb er zelfs een jaren geleden geschreven. Maar degene die ik aanbeveel als je wilt iets heel eenvoudigs is easy-rsa van het OpenVPN-project. Het is een heel dun omhulsel rond het OpenSSL-opdrachtregelprogramma. Als je VEEL certificaten gaat beheren en daadwerkelijk te maken hebt met intrekking en zo, dan wil je een veel complexer en feature-compleet hulpprogramma. Er zijn al meer dan genoeg suggesties gegeven, dus in plaats daarvan blijf ik gewoon bij de basis van wat je probeert te bereiken.

Maar hier is de basisprocedure. Ik zal het uitleggen met OpenSSL , maar elk systeem zal het doen.

Begin met het maken van uw “root” CA – het zal een zelfondertekend certificaat zijn. Er zijn verschillende manieren om dit te doen; dit is er een. We zullen ervoor zorgen dat van ons een certificaat van 10 jaar met een 2048-bitsleutel.Pas de nummers naar wens aan. Je zei dat je je zorgen maakte over het hash-algoritme, dus ik heb -sha256 toegevoegd om er zeker van te zijn dat het is ondertekend met iets acceptabels. Ik codeer de sleutel met AES-256, maar dat is optioneel . U wordt gevraagd de certificaatnaam en dergelijke in te vullen; die details zijn “niet bijzonder belangrijk voor een 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 

Als je de sleutel in de eerste stap hebt versleuteld, moet je het wachtwoord opgeven voor gebruik het in de tweede. Controleer uw gegenereerde certificaat om er zeker van te zijn dat u onder “Basic Constraints” “CA: TRUE” ziet staan. Dat is echt het enige belangrijke punt waar u zich zorgen over hoeft te maken:

openssl x509 -text < root.cer 

Cool. OK, laten we nu een certificaat ondertekenen. We hebben nog een sleutel nodig en dit keer een verzoek. U wordt opnieuw gevraagd naar uw naam en adres. Welke velden u invult en wat u opgeeft, is aan u en uw toepassing, maar het veld dat het belangrijkst is, is de “Common Name”. Dat is waar u uw hostnaam of inlognaam opgeeft of wat dit certificaat ook gaat bevestigen.

# 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 op dat hierdoor een bestand met de naam root.srl wordt gemaakt naar houd onze serienummers recht. De vlag -CAcreateserial vertelt openssl om dit bestand te maken, dus u geeft het op voor het eerste verzoek dat u ondertekent en dan nooit meer. En nogmaals, u kunt zien waar om het -sha256 argument toe te voegen.

Deze aanpak – alles handmatig doen – is naar mijn mening niet het beste idee. Als je een flinke operatie uitvoert , dan wil je waarschijnlijk een tool die al je certificaten voor je kan bijhouden.

In plaats daarvan was mijn punt hier om je te laten zien dat de output die je wilt – de certificaten ondertekend zoals jij wilt ze – is niet afhankelijk van de tools die je gebruikt, maar eerder van de opties die je aan die tools biedt. De meeste tools kunnen een grote verscheidenheid aan configuraties uitvoeren, zowel sterke als zwakke, en het is aan jou om de cijfers op te geven m gepast. Verouderde standaardwaarden zijn normaal voor de cursus.

Reacties

• Het ‘ is belangrijk om op te merken dat wanneer u ondertekent een clientcertificaat, dit is alleen het openbare gedeelte. Er mag geen privésleutel worden verzonden of gegenereerd door de CA.
• Kunt u uw antwoord op het maken van een tussenliggend CA-certificaat uitbreiden? Bedankt.
• @Andr é Tussenliggende certificaten zijn gewoon normale certificaten met basicConstraints = CA:TRUE ingesteld in hun uitgebreide attributen. Niets magisch, gewoon weer een certificaat.
• @tylerl Kerel, jij rockt.
• Dit antwoord is FANTASTISCH en was super behulpzaam, maar ik moet een update uit 2017 toevoegen. Chrome en anderen hebben nu de extensie x509v3 subjectAlternativeName nodig; anders beschouwen ze het certificaat als ongeldig, zelfs als een CA-basiscertificaat correct op het systeem is geïnstalleerd. Ik heb een tijdje geworsteld met het bedenken van de juiste oplossing. Deze pagina was voor mij van onschatbare waarde en loste het laatste stukje van de puzzel voor mij op: cmrg.fifthhorseman.net/wiki/SubjectAltName . IMO, het toevoegen van de SAN bij het ondertekenen, in plaats van bij het aanvragen, is zowel gemakkelijker als meer zoals de openbare CAs eigenlijk doen.

Als u echt een CA wilt zijn, houd dan rekening met de beveiligingsimplicaties hiervan.

1. De privésleutel die wordt gebruikt om de root-CA voor uw intranet te genereren, moet letterlijk worden opgesloten in een kluis. En toegang tot de kluis moet fysiek worden gecontroleerd.
2. Het gebruik van een zelfondertekende root-CA dwingt je gebruikers om niet alleen erop te vertrouwen dat je de nodige zorgvuldigheid betracht bij het veilig bewaken van sleutels, maar ook om een aanvankelijk niet-vertrouwde root in te voegen can in hun certificaatketen.
3. Dit breekt ook de OSCP-nietfunctionaliteit met betrekking tot externe verificatie van de certificaatketen, wat de reden is dat identiteitsbeheerdiensten in de eerste plaats bestaan.

Er zijn er nogal wat die de redenering achter het beheren van uw eigen CA zouden beargumenteren, zoals; het is voor een bedrijfsintranet waar een deel van onze desktop builds de root ca bevat of het is voor een klein aantal gebruikers.

Hoewel het niet per se verkeerd is om het te doen en het enkele voordelen kan opleveren, is het wel ontkracht de verificatieketen waarvoor op certificaten gebaseerd identiteitsbeheer is gebouwd.

Als u besluit uw eigen root-ca te implementeren, zorg er dan voor dat u dezelfde beveiligingspraktijken volgt als alle andere root-cas gebruiken. Als bedrijf Het laatste dat u zou willen, is dat iemand de privésleutel die voor uw root-ca wordt gebruikt, compromitteert en begint met het ondertekenen van certificaten voor phishing-campagnes tegen uw klanten.

Hiervoor zijn talloze best practices-gidsen beschikbaar, NIST ( nationaal instituut voor standaarden en technologie) is een samenwerkingsgroep die assisteert bij verschillende standaarden voor computerbeveiligingsthemas.

Aanbevolen literatuur:
Auditing (pdf)
Noodherstel (PDF)
Systemen met openbare sleutels (PDF)
Sans institute over kleinere PKI-implementaties

Ok ik zie dat je je vraag hebt bijgewerkt om specifieker te zijn.

Twee documenten voor het configureren van je openssl.cnf-bestand voor CA-details:

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

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

Ik realiseer me dat dit misschien niet het antwoord is dat je wilt, maar omdat ieders omgeving en vereisten anders zijn, ga je moet een scope definiëren voor uw CA-implementatie voor een goed voorbeeldconfiguratie.

Reacties

• Daar ‘ Het is geen reden waarom uw eigen CA ‘ geen OCSP kan doen. Zelfs de OpenSSL-opdrachtregel kan het, en dat ‘ s ongeveer de laagst mogelijke balk.
• openssl-links zijn nu 404

Daar is geen manier om dit eenvoudig te doen. er zijn enkele tools die u kunnen helpen om gemakkelijk aan de slag te gaan.

zoals:

• XCA
• EJBCA
• openssl

geen van hen is een volledige PKI afgezien van mogelijk EJBCA, maar dat is niet triviaal om op te zetten.

• XCA is een kleine frontend-tool om een grafische interface te krijgen voor het genereren, ondertekenen en intrekken van certificaten.
• EJBCA of Enterprise Java Beans Certificate Authority is een JBOSS / Jetty-webapp die de volledige PKI-infrastructuur voor een onderneming kan uitvoeren.
• openssl is het basisopdrachtregelprogramma. het kan alle offline bits van een CA uitvoeren, maar geen enkele verificatie (uit de doos). je kunt er je eigen OCSP Verifiers mee maken, maar je moet er zelf de “online” code voor maken.

Als alles wat je zoekt de juiste openssl-configuratie is. XCA kan u helpen deze te genereren. (het heeft een openssl-configuratie-exportfunctie.

Reacties

• EJBCA heeft nu een VM-afbeelding die je kunt gebruiken. Anders ” niet triviaal om ” in te stellen kan als een understatement worden beschouwd. Het is in feite een enorm ant script dat probeert het ( JBoss) applicatieserver die kan (en in mijn geval zal ) kapot gaan.
• de VM-afbeelding is of evaluatiedoeleinden, dus ik zou het niet aanbevelen voor een productieserver.
• Ik zou naar XCA kunnen kijken. EJBCA is beslist geen ‘ t een optie – een webinterface voegt een onnodig aanvalsoppervlak toe en is moeilijker op te zetten. Ik gebruik absoluut liever alleen openssl.
• @Andr é wat betreft EJBCA, het kan ook vanaf de opdrachtregel worden gebruikt, dus je wint ‘ t hoeft de webinterface niet bloot te stellen. Maar het ‘ is iets op ondernemingsniveau en waarschijnlijk overdreven voor jouw doel es (en ik zeg dit als iemand die er zijn brood mee verdient door ermee te werken).

Voor sommigen goede achtergrond, zie mijn presentatie Hoe u uw eigen centrum voor certificaatbeheer van middelmatigheid bouwt en exploiteert . De essentie van de presentatie is dat het meest vereiste niet een lijst is van de uit te voeren opdrachten, maar eerder een diep begrip van alle verschillende bedieningselementen die nodig zijn om een commerciële CA te bedienen, hoe ze samenwerken, de exacte impact van het verwijderen van een ervan, de cumulatieve impact van het verwijderen van een aantal ervan, en de beperkende maatregelen die nodig zijn om de verminderde beveiliging te compenseren.

Daarom is er geen “canoniek antwoord over het opzetten van een eenvoudige CA”. je gaat de hele ISO-route, te beginnen met een partij voor het ondertekenen van sleutels, dubbele rootcertificaten met airgapped en gewelfde dubbele rootcertificaten, meerdere tussenliggende ondertekenaars, intrekkingsservers, enz., enz., Of anders moet je een compromis sluiten op basis van de unieke kosten / baten en risicos profiel dat het bedrijf wil accepteren Iedereen met voldoende vaardigheid en ervaring om die evaluatie te maken heeft per definitie de spiekbrief niet nodig. Ze kunnen de juiste opdrachtsyntaxis ontleden op basis van een diep begrip van de bedrijfsfunctie die moet worden uitgevoerd en de beveiligingsprimitieven die worden gebruikt om die vereiste te implementeren.

In de presentatie staan verhalen over echte engagementen van winkels die deze weg insloegen en het vreselijk bij het verkeerde eind hadden. In sommige gevallen meldde mijn beoordeling dat absoluut niets dat ik kan doen met uw middlewarebeveiliging, mogelijk de inherente zwakheden van de interne CA kan verhelpen. Iedereen in de VS moet zich realiseren dat ze waarschijnlijk diensten kopen van ten minste een van de leveranciers waarnaar de presentatie verwijst. Dit zijn banken, kredietverenigingen, zorgverzekeraars, winkeliers en meer.

Aangezien om de aanbevelingen correct te laten zijn, vereist dat de beantwoorder belangrijke aannames doet over uw aanvaardbare risicoprofielen, en dat u belangrijke aannames doet over de mate waarin uw en hun ideeën over risicos zijn afgestemd en synchroon is het voorstel zelf riskant op het eerste gezicht. In de meeste van dergelijke gevallen heeft de beoordeling van de geschiktheid van aangeboden werkcolleges meer te maken met de presentatie dan met het effectieve niveau van beveiliging als gevolg van het volgen van hun procedures. Als het goed georganiseerd en duidelijk gearticuleerd is, is dit VEEL belangrijker dan of het effectief is. We kiezen het canonieke spiekbriefje dat ons er het beste uitziet .

Om deze redenen geloof ik niet dat een geloofwaardige expert “correct en actueel bestanden”, maar kan in het beste geval een evaluatieproces bieden om de vereisten en het aanvaardbare risico vollediger te beoordelen. Aangezien u het bedrijf op het resultaat gokt, zou geen enkele geloofwaardige expert dit doen buiten de bescherming van een contract. Alle aanbevelingen die u krijgt, moeten bijna per definitie afkomstig zijn van een in geloofwaardige expert. Veel succes.

Opmerkingen

• Zelfs voor een intranet voor interne bronnen? U kunt ook aangeven dat de presentatie van u is.
• ” Zelfs voor een intranet voor interne bronnen? ” Vooral voor het intranet sinds dat ‘ s waar de meeste datalekken plaatsvinden. ” Wellicht wilt u ook aangeven dat de presentatie van jou is. ” Ik dacht dat ik die had bij het beschrijven van mijn ervaring met het uitvoeren van de assessments, maar het punt was goed. Ik ‘ heb het bijgewerkt.

Volg deze instructies om een Windows-gebaseerde CA te configureren. Aangezien u clientcertificaten uitgeeft, moet u er rekening mee houden dat SHA2-hashes “niet worden ondersteund op XP.

Het simpele antwoord is:

1. AD installeren
2. Installeer een Enterprise CA op de domeincontroller
3. Bewerk de certificaatsjabloon om eindgebruikerscertificaten uit te geven (stel de toestemming in voor gebruikers om zichzelf in te schrijven of ga naar een webpagina)
4. Implementeer de openbare sleutel van het rootcertificaat op alle servers die gebruikers valideren.
5. Als de gebruikers zich op AD bevinden, gebruik dan GPO om automatische inschrijving in te schakelen