14.4.4. Certificate semnate de CA (de încredere publică)

Certificatele autosemnate funcționează atunci când controlezi ambele capete. Dacă în schimb clienți oarecare (browsere, telefoane, software terț) trebuie să se conecteze la cameră fără a li se cere să aibă încredere într-un certificat personalizat, certificatul trebuie semnat de o autoritate de certificare (CA) publică în care acei clienți au deja încredere. Codul TLS de pe cameră este identic cu cazul autosemnat – load_cert_chain cu un certificat și o cheie în formă DER – se schimbă doar modul în care obții acel certificat.

Cel mai important aspect: îți generezi tu însuți cheia privată, iar aceasta nu părăsește niciodată mașina ta. CA-ul nu o vede niciodată. Ceea ce trimiți CA-ului este o cerere de semnare a certificatului (CSR) – un fișier mic ce conține cheia ta publică și numele tău de domeniu – iar ceea ce primești înapoi este un certificat (cheia ta publică și numele tău, semnate de CA). Cheia și certificatul sunt două fișiere separate produse de doi pași separați; CA-ul manipulează doar jumătatea publică.

Fluxul general, realizat în întregime pe o mașină obișnuită (niciodată pe cameră):

  1. Obține un nume de domeniu. CA-urile publice certifică un nume DNS pe care îl controlezi (de ex. cam.example.com); ele nu vor emite pentru o adresă IP simplă sau pentru un nume doar local precum mycam.

  2. Generează o cheie și un CSR. O singură comandă OpenSSL produce cheia privată și CSR-ul corespunzător. Folosește același tip de cheie pe care l-ai folosi pentru un certificat autosemnat (vezi Concepte: încredere, chei și formatul fișierelor); este recomandat ECDSA P-256.

    ECDSA P-256 – recomandat:

    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 – mai puternic, mai mare/mai lent:

    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 – compatibilitate maximă:

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

    Păstrează domain.key secret – acesta este fișierul de cheie pe care îl vei pune în cele din urmă pe cameră. domain.csr este fișierul pe care îl predai CA-ului; nu conține niciun secret.

  3. Trimite CSR-ul și dovedește că deții controlul asupra domeniului. Aici diferă cele două căi obișnuite:

    • Un CA ACME automatizat precum Let’s Encrypt, condus de un instrument precum certbot sau acme.sh, execută pașii 2 și 3 în locul tău: generează cheia, construiește CSR-ul, răspunde automat la provocare (HTTP-01: servește un token prin portul 80 pe domeniu, sau DNS-01: publică o înregistrare TXT în DNS-ul său) și scrie fișierele finalizate.

    • Un CA comercial (cumpărat direct sau printr-un revânzător de domenii/hosting): inserezi textul domain.csr într-un formular web, apoi dovedești controlul răspunzând la un e-mail de validare, publicând o înregistrare DNS sau plasând un fișier pe un server web pentru acel domeniu. După validare, descarci fișierele emise.

  4. Adună fișierele emise. Pentru a înțelege ce primești, este util să știi că certificatele formează un lanț de încredere: certificatul domeniului tău este semnat de un CA intermediar, care la rândul său este semnat de un CA rădăcină. Fiecare verigă garantează pentru cea de sub ea. Vei ajunge să ai:

    • Cheia ta privată (de la pasul 2). CA-ul nu a avut-o niciodată; rămâne pe mașina ta și este cheia pe care o vei pune în cele din urmă pe cameră.

    • Certificatul leaf – numit și certificat de entitate finală sau de server. Acesta este certificatul pentru domeniul tău specific (cam.example.com): conține cheia ta publică și numele tău și este semnat de intermediarul CA-ului. Acesta este certificatul pe care camera îl prezintă pentru a se identifica.

    • Unul sau mai multe certificate CA intermediare („lanțul” sau „pachetul CA”). Un CA nu îți semnează leaf-ul direct cu rădăcina sa – cheia rădăcinii este păstrată offline și puternic protejată – așa că semnează cu un intermediar, care este la rândul său semnat de rădăcină. Intermediarul este veriga care conectează leaf-ul tău în sus, până la rădăcină.

    Certificatul rădăcină este ancora de încredere: un certificat autosemnat care aparține CA-ului și care se află la vârful lanțului. Nu îți este oferit și nu îl implementezi niciodată, deoarece fiecare client îl are deja – sistemele de operare, browserele, telefoanele și mediile de execuție ale limbajelor sunt livrate cu un „magazin de încredere” încorporat de certificate rădăcină. Un client are încredere în leaf-ul tău parcurgând lanțul: are deja încredere în rădăcină, rădăcina garantează pentru intermediar, iar intermediarul garantează pentru leaf-ul tău. (Exact asta face unicul tău fișier server.der / cafile în cazul autosemnat – acolo tu ești propria ta rădăcină.)

    Un fișier fullchain este pur și simplu leaf-ul și intermediarul (intermediarii) concatenați într-un singur fișier, leaf-ul primul, în mod deliberat fără rădăcină (trimiterea rădăcinii nu are sens – un client are încredere doar în rădăcinile pe care le are deja). Un server obișnuit prezintă acest fullchain întreg, astfel încât orice client să-l poată parcurge. Camera nu poate: ea încarcă și prezintă un singur certificat – leaf-ul – și nu poate trimite și certificatul (certificatele) intermediar(e) pe care ți le-a dat CA-ul.

    Nume de fișiere pe care le vei vedea efectiv: un instrument ACME precum certbot scrie privkey.pem (cheia ta), cert.pem (doar leaf-ul), chain.pem (doar intermediarul/intermediarii) și fullchain.pem (leaf + intermediar/intermediari). Un CA comercial îți oferă de obicei un .crt pentru leaf și un .ca-bundle pentru intermediar(i), iar .key fiind cel pe care l-ai generat tu însuți.

  5. Convertește și copiază. Convertește cheia privată și certificatul leaf în DER și copiază-le pe cameră exact ca pe Certificate auto-semnate. Camera le prezintă apoi ca certificat de server al său, iar clienții standard acceptă automat conexiunea, deoarece au deja încredere în CA – nu este necesară nicio configurare de partea clientului.

Sfat

În practică, faptul că camera prezintă doar leaf-ul (și niciodată intermediarii) se desfășoară astfel:

  • Clienții care au deja intermediarul CA-ului în cache – browserele mainstream și bibliotecile HTTPS de obicei îl au – completează singuri lanțul și se conectează fără probleme.

  • Clienții care se bazează pe server pentru a furniza intermediarul vor eșua la handshake-ul cu camera.

Dacă fiecare client posibil trebuie să reușească, nu termina TLS public direct pe cameră. Pune un gateway / proxy invers în fața ei care să servească lanțul complet către exterior și fă ca proxy-ul să ajungă la cameră prin fluxul autosemnat descris mai sus.