Opprette og administrere sertifikatkjeder

En rot-CA er et selvsignert sertifikat som fungerer som det overordnede tillitsankeret. Den private nøkkelen til rot-CA-en må oppbevares frakoblet nettverket (på et luftisolert system eller i en HSM), fordi et kompromiss vil undergrave hele PKI-en. "openssl req -x509 -new -nodes -key root_key.pem -sha256 -days 3650 -out root_cert.pem" genererer et selvsignert rotsertifikat som er gyldig i 10 år.

Mellomliggende CA-er signeres av rot-CA-en og brukes til daglig utstedelse av sertifikater. Først genereres nøkkelen og CSR-en for den mellomliggende CA-en: "openssl req -new -key intermediate_key.pem -out intermediate.csr". Deretter signerer rot-CA-en den: "openssl x509 -req -in intermediate.csr -CA root_cert.pem -CAkey root_key.pem -CAcreateserial -days 1825 -out intermediate_cert.pem".

Sluttentitetssertifikater (leaf-sertifikater) signeres av den mellomliggende CA-en for bestemte servere eller klienter. Servernøkkelen og CSR-en genereres med Subject Alternative Names (SAN-er), og signeres deretter med den mellomliggende 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økkelen til rot-CA-en oppbevares frakoblet nettverket og brukes bare til å signere et lite antall sertifikater for mellomliggende CA-er. Daglig sertifikatutstedelse utføres av mellomliggende CA-er som er tilkoblet nettverket. Hvis en mellomliggende CA kompromitteres, kan den tilbakekalles og erstattes uten at roten kompromitteres. Rotnøkkelen forblir sikker fordi den aldri var eksponert på nettet.

Kommandoen "openssl ca" gir en mer komplett CA-arbeidsflyt enn "openssl x509 -req". Den vedlikeholder en sertifikatdatabase (index.txt), tildeler serienumre fra en serial-fil og håndterer generering av CRL-er. Den krever en korrekt konfigurasjonsfil for openssl.cnf med CA-spesifikke seksjoner som definerer sertifikatpolicyen og begrensninger for path length.

En komplett sertifikatkjedefil for en webserver inneholder sluttentitetssertifikatet etterfulgt av sertifikater for mellomliggende CA-er i riktig rekkefølge, og avsluttes rett før roten. Rotsertifikater tas ikke med fordi nettlesere har forhåndsinstallerte tillitslagre. Sammenføyningsrekkefølge: "cat server_cert.pem intermediate_cert.pem > chain.pem". Feil rekkefølge fører til feil i TLS-håndtrykket.

"openssl verify -CAfile root_cert.pem -untrusted intermediate_cert.pem server_cert.pem" verifiserer hele kjeden. Flagget "-untrusted" angir mellomliggende sertifikater som inngår i kjeden, men som ennå ikke er klarert. Hvis verifiseringen lykkes, blir resultatet "server_cert.pem: OK". Vanlige feil tyder på manglende mellomliggende sertifikater eller utløpte sertifikater.

Vanlige problemer med sertifikatkjeder er: manglende mellomliggende sertifikater (serveren sender bare leaf-sertifikatet), feil sammenføyningsrekkefølge (leaf-sertifikatet må komme først), utløpt mellomliggende sertifikat (lett å overse siden utløpsdatoen til leaf-sertifikatet overvåkes), selvsignerte sertifikater som ikke finnes i tillitslageret, og navneavvik (sertifikatets SAN samsvarer ikke med vertsnavnet). Alle kan diagnostiseres med "openssl s_client -showcerts".

PKCS#12 (.pfx eller .p12) er et containerformat som samler den private nøkkelen, sluttentitetssertifikatet og mellomliggende sertifikater i én kryptert fil. Opprett: "openssl pkcs12 -export -out bundle.pfx -inkey server_key.pem -in server_cert.pem -certfile intermediate_cert.pem". Kreves av IIS, .NET, Java-nøkkellagre og mange virksomhetsapplikasjoner.

PEM er base64-kodet ASCII, lesbart for mennesker, støtter flere objekter i én fil og brukes av Apache, nginx og OpenSSL-verktøy. DER er binært, har ett objekt per fil og brukes av Java (ved JKS-import), Android og enkelte virksomhetsverktøy. PKCS#12/PFX er en kryptert binær container for flere objekter og brukes av Windows og IIS. Finn ut hvilket format målsystemet forventer før distribusjon.

Moderne CA-er er pålagt å loggføre alle utstedte sertifikater i logger for Certificate Transparency (CT) før de leveres. Når du oppretter en privat CA for intern bruk, er CT-logging ikke nødvendig. Offentlig tilgjengelige sertifikater må imidlertid ha innebygde Signed Certificate Timestamps (SCT-er) for å bli klarert av Chrome. Private CA-er kan bruke egne retningslinjer uten CT-krav.

Rot-CA-er er selvsignerte, oppbevares frakoblet nettverket og signerer bare mellomliggende CA-er. Mellomliggende CA-er håndterer den daglige utstedelsen. Kjedefiler inneholder leaf-sertifikatet etterfulgt av mellomliggende sertifikater (roten utelates). Verifiser med "openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem". PKCS#12-pakker samler nøkkel og sertifikater for Windows/Java. Feil rekkefølge i kjeden er en vanlig årsak til distribusjonsfeil og kan diagnostiseres med s_client -showcerts.