14.4.4. Certyfikaty podpisane przez CA (publicznie zaufane)

Certyfikaty samopodpisane sprawdzają się, gdy kontrolujesz oba końce. Jeśli natomiast dowolni klienci (przeglądarki, telefony, oprogramowanie firm trzecich) muszą łączyć się z kamerą bez instrukcji, by zaufać niestandardowemu certyfikatowi, certyfikat musi być podpisany przez publiczny urząd certyfikacji (CA), któremu ci klienci już ufają. Kod TLS na kamerze jest identyczny jak w przypadku certyfikatu samopodpisanego – load_cert_chain z certyfikatem i kluczem w postaci DER – zmienia się tylko sposób, w jaki uzyskujesz ten certyfikat.

Najważniejsza kwestia: klucz prywatny generujesz samodzielnie i nigdy nie opuszcza on twojej maszyny. Urząd CA nigdy go nie widzi. To, co wysyłasz do urzędu CA, to żądanie podpisania certyfikatu (CSR) – mały plik zawierający twój klucz publiczny i nazwę domeny – a to, co otrzymujesz z powrotem, to certyfikat (twój klucz publiczny i nazwa, podpisane przez urząd CA). Klucz i certyfikat to dwa osobne pliki tworzone w dwóch osobnych krokach; urząd CA zawsze obsługuje tylko publiczną połowę.

Ogólny przebieg, wykonywany w całości na zwykłej maszynie (nigdy na kamerze):

  1. Zdobądź nazwę domeny. Publiczne urzędy CA certyfikują nazwę DNS, którą kontrolujesz (np. cam.example.com); nie wystawią certyfikatu dla samego adresu IP ani dla nazwy działającej tylko lokalnie, takiej jak mycam.

  2. Wygeneruj klucz i CSR. Jedno polecenie OpenSSL tworzy klucz prywatny i pasujący do niego CSR. Użyj tego samego typu klucza, którego użyłbyś dla certyfikatu samopodpisanego (zobacz Pojęcia: zaufanie, klucze i format pliku); zalecane jest ECDSA P-256.

    ECDSA P-256 – zalecane:

    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 – silniejsze, większe/wolniejsze:

    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 – maksymalna kompatybilność:

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

    Trzymaj domain.key w tajemnicy – to plik klucza, który ostatecznie umieścisz na kamerze. domain.csr to plik, który przekazujesz urzędowi CA; nie zawiera on żadnych tajemnic.

  3. Prześlij CSR i udowodnij, że kontrolujesz domenę. Tutaj różnią się dwie popularne ścieżki:

    • Zautomatyzowany urząd CA typu ACME, taki jak Let’s Encrypt, sterowany narzędziem takim jak certbot lub acme.sh, wykonuje za ciebie kroki 2 i 3: generuje klucz, buduje CSR, automatycznie odpowiada na wyzwanie (HTTP-01: serwowanie tokenu przez port 80 w domenie, lub DNS-01: opublikowanie rekordu TXT w jej DNS) i zapisuje gotowe pliki.

    • Komercyjny urząd CA (kupiony bezpośrednio lub przez sprzedawcę domen/hostingu): wklejasz tekst domain.csr do formularza internetowego, a następnie udowadniasz kontrolę, odpowiadając na e-mail weryfikacyjny, publikując rekord DNS lub umieszczając plik na serwerze WWW dla tej domeny. Po zweryfikowaniu pobierasz wystawione pliki.

  4. Zbierz wystawione pliki. Aby zrozumieć, co otrzymujesz, warto wiedzieć, że certyfikaty tworzą łańcuch zaufania: certyfikat twojej domeny jest podpisany przez pośredni urząd CA, który z kolei jest podpisany przez główny urząd CA. Każde ogniwo ręczy za to znajdujące się poniżej. Ostatecznie otrzymujesz:

    • Twój klucz prywatny (z kroku 2). Urząd CA nigdy go nie miał; pozostaje na twojej maszynie i jest kluczem, który ostatecznie umieścisz na kamerze.

    • Certyfikat końcowy (leaf) – nazywany również certyfikatem jednostki końcowej (end-entity) lub serwera. To certyfikat dla twojej konkretnej domeny (cam.example.com): zawiera twój klucz publiczny i nazwę oraz jest podpisany przez certyfikat pośredni urzędu CA. To certyfikat, który kamera prezentuje, aby się zidentyfikować.

    • Jeden lub więcej certyfikatów pośrednich CA („łańcuch” lub „pakiet CA”). Urząd CA nie podpisuje twojego certyfikatu końcowego bezpośrednio swoim certyfikatem głównym – klucz certyfikatu głównego jest przechowywany offline i mocno chroniony – więc podpisuje go certyfikatem pośrednim, który sam jest podpisany przez certyfikat główny. Certyfikat pośredni to ogniwo łączące twój certyfikat końcowy z głównym.

    Certyfikat główny to kotwica zaufania: certyfikat samopodpisany należący do urzędu CA, który znajduje się na szczycie łańcucha. Nie otrzymujesz go i nigdy nie wdrażasz, ponieważ każdy klient już go ma – systemy operacyjne, przeglądarki, telefony i środowiska uruchomieniowe języków programowania są dostarczane z wbudowanym „magazynem zaufania” certyfikatów głównych. Klient ufa twojemu certyfikatowi końcowemu, przechodząc przez łańcuch: ufa już certyfikatowi głównemu, certyfikat główny ręczy za pośredni, a pośredni ręczy za twój certyfikat końcowy. (To dokładnie zadanie, które wykonuje twój pojedynczy server.der / cafile w przypadku certyfikatu samopodpisanego – tam ty jesteś swoim własnym certyfikatem głównym.)

    Plik fullchain to po prostu certyfikat końcowy i certyfikaty pośrednie połączone w jeden plik, najpierw końcowy, celowo bez certyfikatu głównego (wysyłanie certyfikatu głównego jest bezcelowe – klient ufa tylko tym certyfikatom głównym, które już ma). Normalny serwer prezentuje cały ten fullchain, aby dowolny klient mógł przez niego przejść. Kamera tego nie potrafi: ładuje i prezentuje jeden certyfikat – końcowy – i nie może również wysłać certyfikatów pośrednich, które dał ci urząd CA.

    Nazwy plików, które faktycznie zobaczysz: narzędzie ACME, takie jak certbot, zapisuje privkey.pem (twój klucz), cert.pem (sam certyfikat końcowy), chain.pem (same certyfikaty pośrednie) oraz fullchain.pem (końcowy + pośrednie). Komercyjny urząd CA zwykle daje ci plik .crt dla certyfikatu końcowego i .ca-bundle dla certyfikatów pośrednich, przy czym .key to ten, który wygenerowałeś samodzielnie.

  5. Przekonwertuj i skopiuj. Przekonwertuj klucz prywatny i certyfikat końcowy na DER i skopiuj je do kamery dokładnie tak jak na stronie Certyfikaty self-signed. Kamera prezentuje je następnie jako swój certyfikat serwera, a standardowi klienci automatycznie akceptują połączenie, ponieważ już ufają urzędowi CA – nie jest potrzebna żadna konfiguracja po stronie klienta.

Wskazówka

W praktyce kamera prezentująca tylko certyfikat końcowy (a nigdy pośrednie) działa w następujący sposób:

  • Klienci, którzy mają już zapisany w pamięci podręcznej certyfikat pośredni urzędu CA – popularne przeglądarki i biblioteki HTTPS zwykle go mają – samodzielnie uzupełniają łańcuch i łączą się bez problemu.

  • Klienci polegający na serwerze w kwestii dostarczenia certyfikatu pośredniego nie przejdą uzgadniania połączenia (handshake) z kamerą.

Jeśli każdy możliwy klient musi się powieść, nie kończ publicznego TLS bezpośrednio na kamerze. Umieść przed nią bramę / odwrotne proxy, które serwuje pełny łańcuch światu zewnętrznemu, i niech proxy łączy się z kamerą za pomocą opisanego powyżej przepływu z certyfikatem samopodpisanym.