Oprettelse og administration af certifikatkæder

En rod-CA er et selvsigneret certifikat, der fungerer som den øverste tillidsforankring. Den private nøgle til rod-CA'en skal opbevares offline (på et isoleret system uden netværksforbindelse eller i et HSM), fordi en kompromittering af den underminerer hele PKI'en. "openssl req -x509 -new -nodes -key root_key.pem -sha256 -days 3650 -out root_cert.pem" genererer et selvsigneret rodcertifikat, der er gyldigt i 10 år.

Mellem-CA'er signeres af rod-CA'en og bruges til daglig certifikatudstedelse. Generér først mellem-CA'ens nøgle og CSR: "openssl req -new -key intermediate_key.pem -out intermediate.csr". Derefter signerer rod-CA'en den: "openssl x509 -req -in intermediate.csr -CA root_cert.pem -CAkey root_key.pem -CAcreateserial -days 1825 -out intermediate_cert.pem".

Slutentitetscertifikater (bladcertifikater) signeres af mellem-CA'en for bestemte servere eller klienter. Generér servernøglen og CSR'en med alternative subjektnavne (SAN'er), og signér derefter med mellem-CA'en: "openssl x509 -req -in server.csr -CA intermediate_cert.pem -CAkey intermediate_key.pem -CAcreateserial -extensions v3_req -days 365 -out server_cert.pem".

Den private nøgle til rod-CA'en opbevares offline og bruges kun til at signere et lille antal certifikater for mellem-CA'er. Den daglige certifikatudstedelse udføres af online-mellem-CA'er. Hvis en mellem-CA kompromitteres, kan den tilbagekaldes og erstattes uden at kompromittere roden. Rodnøglen forbliver sikker, fordi den aldrig var tilgængelig online.

Kommandoen "openssl ca" giver en mere komplet CA-arbejdsgang end "openssl x509 -req". Den vedligeholder en certifikatdatabase (index.txt), tildeler serienumre fra en serienummerfil og håndterer generering af CRL'er. Den kræver en korrekt konfigurationsfil openssl.cnf med CA-specifikke sektioner, der definerer certifikatpolitikken og begrænsninger for certificeringskædens længde.

En komplet certifikatkædefil til en webserver indeholder slutentitetscertifikatet efterfulgt af mellem-CA-certifikater i rækkefølge og slutter lige før roden. Rodcertifikater medtages ikke, fordi browsere har forudinstallerede rodcertifikatlager. Sammenkædningsrækkefølge: "cat server_cert.pem intermediate_cert.pem > chain.pem". Forkert rækkefølge medfører fejl under TLS-håndtrykket.

"openssl verify -CAfile root_cert.pem -untrusted intermediate_cert.pem server_cert.pem" verificerer hele kæden. Tilvalget "-untrusted" leverer mellemcertifikater, der er en del af kæden, men endnu ikke er betroede. Hvis verificeringen lykkes, er outputtet "server_cert.pem: OK". Almindelige fejl skyldes manglende mellemcertifikater eller udløbne certifikater.

Hyppige problemer med certifikatkæder omfatter: manglende mellemcertifikater (serveren sender kun slutentitetscertifikatet), forkert sammenkædningsrækkefølge (slutentitetscertifikatet skal stå først), et udløbet mellemcertifikat (overses let, fordi slutentitetscertifikatets udløb overvåges), selvsignerede certifikater, der ikke findes i tillidslageret, og navneuoverensstemmelse (certifikatets SAN matcher ikke værtsnavnet). Alle problemer kan diagnosticeres med "openssl s_client -showcerts".

PKCS#12 (.pfx eller .p12) er et containerformat, der samler den private nøgle, slutentitetscertifikatet og mellemcertifikaterne i en enkelt krypteret fil. Opret et bundle med: "openssl pkcs12 -export -out bundle.pfx -inkey server_key.pem -in server_cert.pem -certfile intermediate_cert.pem". Det kræves af IIS, .NET, Java-nøglelagre og mange virksomhedsprogrammer.

PEM er base64-kodet ASCII, læsbart for mennesker, understøtter flere objekter i én fil og bruges af Apache, nginx og OpenSSL-værktøjer. DER er binært, indeholder ét objekt pr. fil og bruges af Java (JKS-importer), Android og nogle virksomhedsværktøjer. PKCS#12/PFX er en krypteret binær container til flere objekter og bruges af Windows og IIS. Kend det forventede format i målsystemet, før du implementerer det.

Moderne CA'er skal logge alle udstedte certifikater i Certificate Transparency-logge, før certifikaterne udleveres. Når du opretter en privat CA til intern brug, kræves logning i CT ikke. Offentligt tilgængelige certifikater skal dog have indlejrede signerede certifikattidsstempler (SCT'er) for at blive accepteret af Chrome. Private CA'er kan anvende egne politikker uden CT-krav.

Rod-CA'er er selvsignerede, opbevares offline og signerer kun mellem-CA'er. Mellem-CA'er håndterer den daglige udstedelse. Kædefiler indeholder først slutentitetscertifikatet og derefter mellemcertifikaterne (roden udelades). Verificér med "openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem". PKCS#12-bundles samler nøgler og certifikater til Windows og Java. Forkert rækkefølge i kæden er en almindelig årsag til fejl ved implementering og kan diagnosticeres med s_client -showcerts.