14.4.4. CA-signerade (publikt betrodda) certifikat

Självsignerade certifikat fungerar när du kontrollerar båda ändarna. Om i stället godtyckliga klienter (webbläsare, telefoner, tredjepartsprogram) måste ansluta till kameran utan att bli tillsagda att lita på ett anpassat certifikat, måste certifikatet vara signerat av en publik certifikatutfärdare (CA) som dessa klienter redan litar på. TLS-koden på kameran är identisk med det självsignerade fallet – load_cert_chain med ett certifikat och en nyckel i DER-form – endast sättet du skaffar det certifikatet på ändras.

Den enskilt viktigaste punkten: du genererar den privata nyckeln själv och den lämnar aldrig din maskin. CA:n ser den aldrig. Det du skickar till CA:n är en begäran om certifikatsignering (CSR) – en liten fil som innehåller din publika nyckel och ditt domännamn – och det du får tillbaka är ett certifikat (din publika nyckel och ditt namn, signerat av CA:n). Nyckeln och certifikatet är två separata filer som produceras i två separata steg; CA:n hanterar bara någonsin den publika halvan.

Det generella flödet, allt utfört på en vanlig maskin (aldrig på kameran):

  1. Skaffa ett domännamn. Publika CA:er certifierar ett DNS-namn du kontrollerar (t.ex. cam.example.com); de utfärdar inte för en bar IP-adress eller ett enbart lokalt namn som mycam.

  2. Generera en nyckel och en CSR. Ett OpenSSL-kommando producerar den privata nyckeln och den matchande CSR:en. Använd samma nyckeltyp som du skulle använda för ett självsignerat certifikat (se Begrepp: förtroende, nycklar och filformat); ECDSA P-256 rekommenderas.

    ECDSA P-256 – rekommenderas:

    openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"

    ECDSA P-384 – starkare, större/långsammare:

    openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:secp384r1 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"

    RSA-2048 – maximal kompatibilitet:

    openssl req -new -newkey rsa:2048 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"

    Håll domain.key hemlig – detta är nyckelfilen du så småningom kommer att lägga på kameran. domain.csr är filen du lämnar till CA:n; den innehåller inga hemligheter.

  3. Skicka in CSR:en och bevisa att du kontrollerar domänen. Det är här de två vanliga vägarna skiljer sig åt:

    • En automatiserad ACME-CA som Let’s Encrypt, driven av ett verktyg som certbot eller acme.sh, gör steg 2 och 3 åt dig: den genererar nyckeln, bygger CSR:en, besvarar utmaningen automatiskt (HTTP-01: servera en token över port 80 på domänen, eller DNS-01: publicera en TXT-post i dess DNS) och skriver ut de färdiga filerna.

    • En kommersiell CA (köpt direkt eller via en domän-/webbhotellsåterförsäljare): du klistrar in texten domain.csr i ett webbformulär, och bevisar sedan kontroll genom att svara på ett valideringsmejl, publicera en DNS-post, eller placera en fil på en webbserver för den domänen. När du väl är validerad laddar du ner de utfärdade filerna.

  4. Samla in de utfärdade filerna. För att förstå vad du tar emot hjälper det att veta att certifikat bildar en förtroendekedja: din domäns certifikat är signerat av en mellanliggande CA, som i sin tur är signerad av en rot-CA. Varje länk går i god för den under den. Du slutar med:

    • Din privata nyckel (från steg 2). CA:n hade den aldrig; den stannar på din maskin och är nyckeln du så småningom lägger på kameran.

    • Löv-certifikatet – även kallat slutenhets- eller server-certifikatet. Detta är certifikatet för din specifika domän (cam.example.com): det innehåller din publika nyckel och ditt namn, och är signerat av CA:ns mellanliggande certifikat. Detta är certifikatet kameran presenterar för att identifiera sig.

    • Ett eller flera mellanliggande CA-certifikat (”kedjan” eller ”CA-bundeln”). En CA signerar inte ditt löv-certifikat direkt med sin rot – rotens nyckel hålls offline och är kraftigt skyddad – så den signerar med ett mellanliggande certifikat, som i sin tur är signerat av roten. Det mellanliggande certifikatet är länken som kopplar ditt löv-certifikat upp till roten.

    Rot-certifikatet är förtroendeankaret: ett självsignerat certifikat som tillhör CA:n och sitter högst upp i kedjan. Du får det inte och distribuerar det aldrig, eftersom varje klient redan har det – operativsystem, webbläsare, telefoner och språkkörningsmiljöer levereras med ett inbyggt ”förtroendelager” av rotcertifikat. En klient litar på ditt löv-certifikat genom att gå igenom kedjan: den litar redan på roten, roten går i god för det mellanliggande certifikatet, och det mellanliggande certifikatet går i god för ditt löv-certifikat. (Detta är precis det jobb din enda server.der / cafile gör i det självsignerade fallet – där är du din egen rot.)

    En fullchain-fil är helt enkelt löv-certifikatet och det/de mellanliggande certifikatet/certifikaten sammanfogade till en fil, löv-certifikatet först, medvetet utan roten (att skicka roten är meningslöst – en klient litar bara på rötter den redan har). En vanlig server presenterar hela denna fullchain så att vilken klient som helst kan gå igenom den. Kameran kan inte: den läser in och presenterar ett certifikat – löv-certifikatet – och kan inte också skicka det/de mellanliggande certifikatet/certifikaten CA:n gav dig.

    Filnamn du faktiskt kommer att se: ett ACME-verktyg som certbot skriver privkey.pem (din nyckel), cert.pem (enbart löv-certifikatet), chain.pem (enbart det/de mellanliggande certifikatet/certifikaten) och fullchain.pem (löv + mellanliggande). En kommersiell CA ger dig vanligtvis en .crt för löv-certifikatet och en .ca-bundle för det/de mellanliggande certifikatet/certifikaten, där .key är den du genererade själv.

  5. Konvertera och kopiera. Konvertera den privata nyckeln och löv-certifikatet till DER och kopiera dem till kameran precis som på Självsignerade certifikat. Kameran presenterar dem sedan som sitt server-certifikat och standardklienter accepterar anslutningen automatiskt, eftersom de redan litar på CA:n – ingen klientsidig konfiguration behövs.

Tips

I praktiken utspelar sig kameran som presenterar enbart löv-certifikatet (och aldrig de mellanliggande) så här:

  • Klienter som redan har CA:ns mellanliggande certifikat cachat – vanliga webbläsare och HTTPS-bibliotek har det oftast – slutför kedjan själva och ansluter utan problem.

  • Klienter som förlitar sig på servern för att tillhandahålla det mellanliggande certifikatet kommer att misslyckas med handskakningen mot kameran.

Om varje möjlig klient måste lyckas, avsluta inte publik TLS direkt på kameran. Sätt en gateway / omvänd proxy framför den som serverar hela kedjan till omvärlden, och låt proxyn nå kameran via det självsignerade flödet som beskrivs ovan.