Jak dodać własny certyfikat CA do Ubuntu

Dodawanie własnego urzędu certyfikacji (CA) do magazynu zaufanych certyfikatów Ubuntu

Aby dodać własny urząd certyfikacji do magazynu zaufanych certyfikatów Ubuntu, należy skopiować certyfikat główny do /usr/local/share/ca-certificates/ pod nazwą kończącą się na .crt, a następnie wykonać polecenie sudo update-ca-certificates. Urząd certyfikacji (CA) to para kluczy, której certyfikat posiada uprawnienia do podpisywania innych certyfikatów. Gdy system zaufa certyfikatowi głównemu, każdy certyfikat przez niego podpisany będzie akceptowany, dzięki czemu weryfikacja HTTPS między własnymi usługami przestanie kończyć się błędem.

Niniejszy przewodnik opisuje tworzenie całego łańcucha w trybie offline przy użyciu openssl. Proces obejmuje wygenerowanie klucza głównego i certyfikatu głównego, wystawienie certyfikatu końcowego dla serwera, a następnie instalację certyfikatu głównego i weryfikację zmiany wyniku polecenia sprawdzającego. Taka kolejność jest kluczowa: weryfikacja przed instalacją i po niej pozwala zaobserwować, że to właśnie instalacja wpłynęła na zmianę wyniku.

Ubuntu 24.04 zawiera OpenSSL 3 oraz pakiet ca-certificates w domyślnym obrazie, więc nie ma potrzeby instalowania dodatkowego oprogramowania (stan na sierpień 2026).

Kiedy należy uruchomić własny urząd certyfikacji (CA)?

Publiczny urząd CA, taki jak Let's Encrypt, wymaga nazwy w publicznym systemie DNS oraz serwera, z którym może nawiązać połączenie. Nazwy wewnętrzne nie spełniają tych wymagań. Baza danych w sieci prywatnej lub panel administracyjny powiązany z tunelem nie mogą uzyskać certyfikatu publicznego i żadnego z nich nie należy wystawiać do Internetu tylko w celu jego uzyskania.

Certyfikat z podpisem własnym w systemie Ubuntu rozwiązuje problem tylko dla jednego hosta. Każdy klient musi zaufać temu jednemu certyfikatowi, a przy kolejnym hoście proces trzeba powtarzać. Prywatny urząd CA przenosi decyzję o zaufaniu na wyższy poziom. Klienci ufają certyfikatowi głównemu (root) tylko raz, a każdy certyfikat podpisany przez ten urząd jest automatycznie uznawany za zaufany, w tym certyfikaty dla hostów, które jeszcze nie istnieją.

Koszty są realne. Klucz główny może podpisać wszystko, na co pozwalają ograniczenia, więc każdy, kto odczyta ca.key, może wystawiać certyfikaty, które Twoje maszyny zaakceptują. Należy go chronić w taki sam sposób, jak klucz prywatny w zarządzaniu kluczami SSH. Jeśli usługa posiada publiczną nazwę DNS, należy pominąć te kroki i skorzystać z publicznego urzędu CA: Certbot z nginx i Let's Encrypt wymaga mniej pracy i nie wymaga instalacji żadnego oprogramowania po stronie klienta.

Tworzenie klucza CA i certyfikatu głównego

Pracuj w katalogu, do którego dostęp ma wyłącznie użytkownik. Klucz główny nigdy nie powinien go opuszczać.

install -d -m 700 ~/ca
cd ~/ca
openssl genrsa -aes256 -out ca.key 4096
chmod 600 ca.key

-aes256 szyfruje klucz wybranym hasłem, o które zapyta każde kolejne polecenie podpisujące tym kluczem. Pominiecie -aes256 sprawi, że klucz będzie zapisany na dysku w postaci jawnej, co oznacza, że kopia zapasowa lub dostęp do konta innego administratora wystarczą, aby umożliwić osobie trzeciej wystawianie certyfikatów zaufanych przez Twoje maszyny.

Teraz certyfikat główny, który klucz CA podpisuje samodzielnie.

openssl req -x509 -new -key ca.key -sha256 -days 3650 \
  -subj "/O=Example Internal/CN=Example Internal Root CA" \
  -addext "basicConstraints=critical,CA:TRUE,pathlen:0" \
  -addext "keyUsage=critical,keyCertSign,cRLSign" \
  -addext "subjectKeyIdentifier=hash" \
  -addext "nameConstraints=critical,permitted;DNS:internal.example" \
  -out ca.crt

Zastąp internal.example używanym przyrostkiem nazwy i przeczytaj następną sekcję przed zachowaniem tego ostatniego rozszerzenia.

Każde rozszerzenie pełni określoną funkcję.

• basicConstraints wraz z CA:TRUE sprawia, że jest to certyfikat CA. Bez tego klient odrzuci każdy certyfikat podpisany tym kluczem, nawet jeśli sam podpis jest poprawny.
• pathlen:0 określa, że CA może podpisywać certyfikaty końcowe, ale nie może tworzyć kolejnych urzędów certyfikacji w hierarchii.
• keyUsage ogranicza użycie klucza wyłącznie do podpisywania certyfikatów i list unieważnień, dzięki czemu ten sam klucz nie może zostać omyłkowo użyty jako klucz serwera TLS.
• subjectKeyIdentifier nadaje certyfikatowi głównemu identyfikator, do którego odwołują się certyfikaty końcowe; w ten sposób klient odnajduje właściwego wystawcę w magazynie zawierającym setki certyfikatów.
• nameConstraints ogranicza nazwy, dla których ten CA może wystawiać certyfikaty.

Sprawdź zawartość utworzonego pliku, zamiast zakładać, że polecenie wykonało zamierzone zadanie.

openssl x509 -noout -subject -issuer -serial -dates -in ca.crt
openssl x509 -noout -text -in ca.crt

Pola Subject oraz Issuer wyświetlają ten sam ciąg znaków, ponieważ certyfikat główny podpisuje się sam. Numer seryjny oraz obie daty pochodzą z pliku, który właśnie utworzono, dlatego należy odczytać je z wyjścia polecenia, a nie z poradników innych osób.

Ograniczenie zakresu podpisywania dla CA

Certyfikat główny (root) w systemowym magazynie certyfikatów jest uznawany za zaufany dla każdej nazwy w Internecie, chyba że skonfigurowano inaczej. To ogromny zakres uprawnień zawarty w jednym pliku na jednym serwerze. nameConstraints ogranicza to ryzyko. Dzięki permitted;DNS:internal.example w certyfikacie głównym, łańcuch certyfikatów wystawiony przez to CA dla nazwy spoza internal.example zostanie odrzucony, nawet jeśli sam podpis jest poprawny.

Należy to przetestować, zamiast zakładać zaufanie.

openssl req -new -newkey rsa:2048 -nodes -keyout /tmp/outside.key -out /tmp/outside.csr \
  -subj "/CN=www.example.com"
openssl x509 -req -in /tmp/outside.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -days 30 -sha256 \
  -extfile <(printf 'subjectAltName=DNS:www.example.com\n') -out /tmp/outside.crt
openssl verify -CAfile ca.crt /tmp/outside.crt
echo $?

Certyfikat zostaje wystawiony, ponieważ CA podpisuje wszystko, o co się je poprosi. Weryfikacja jest momentem, w którym proces kończy się niepowodzeniem: kod wyjścia jest niezerowy, a OpenSSL wskazuje ograniczenie, które zostało naruszone. Na tym polega wartość tego rozszerzenia. Skradziony klucz CA nadal nie pozwoli na wygenerowanie działającego certyfikatu dla nazwy spoza zdefiniowanego poddrzewa. Po zakończeniu usuń pozostałe pliki za pomocą rm /tmp/outside.*.

Oto cztery kwestie, które należy rozważyć przed nałożeniem ograniczenia. Jest ono oznaczone jako critical, więc klient, który nie obsługuje tego rozszerzenia, musi odrzucić łańcuch zamiast je zignorować – jest to bezpieczne podejście, ale może zaskoczyć starsze biblioteki TLS. Dozwolone poddrzewo dla nazw DNS nie ogranicza pól IP address SAN, ponieważ typ nazwy, dla którego nie określono poddrzewa, pozostaje nieograniczony. Jeśli certyfikaty zawierają adresy IP, należy dodać permitted;IP:10.0.0.0/255.255.0.0 w tym samym rozszerzeniu. Poddrzewo musi obejmować każdą nazwę, która kiedykolwiek będzie wystawiana, w tym krótkie nazwy hostów, więc certyfikat dla samej nazwy app nie przeszedłby weryfikacji w powyższym przykładzie. Ograniczenie jest trwale zapisane w certyfikacie głównym, więc zmiana decyzji oznacza konieczność wygenerowania nowego certyfikatu głównego i przeprowadzenia ponownej instalacji na każdym kliencie.

Wystawianie certyfikatu końcowego podpisanego przez własny CA

Certyfikat końcowy (leaf certificate) to certyfikat prezentowany klientom przez serwer. Proces należy rozpocząć od wygenerowania własnego klucza oraz pliku CSR (certificate signing request), który zawiera klucz publiczny oraz żądaną nazwę. Plik ten jest podpisywany kluczem końcowym, co potwierdza, że wnioskodawca posiada część prywatną klucza.

openssl req -new -newkey rsa:2048 -nodes \
  -keyout app.key -out app.csr \
  -subj "/CN=app.internal.example"
chmod 600 app.key

Nazwy, które mają znaczenie, umieszcza się w pliku rozszerzeń, a nie w CSR. Klienci weryfikują nazwę hosta w polu subjectAltName (SAN) i całkowicie ignorują pole common name. Z tego powodu certyfikat posiadający tylko CN, a pozbawiony SAN, nie przejdzie weryfikacji nazwy hosta u żadnego współczesnego klienta, niezależnie od zawartości CN.

basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = DNS:app.internal.example, DNS:api.internal.example
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always

Zapisz to jako app.ext, a następnie podpisz żądanie za pomocą CA.

openssl x509 -req -in app.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -days 397 -sha256 -extfile app.ext -out app.crt

-CAcreateserial tworzy plik ca.srl obok CA, przechowujący kolejny numer seryjny, co zapobiega przypisaniu tego samego numeru dwóm certyfikatom wystawionym przez ten sam CA. Plik ten należy przechowywać w katalogu CA. Wartość -days 397 jest kwestią wyboru, a nie ograniczeniem narzędzia. W tym przypadku krótkie okresy ważności są istotniejsze niż w przypadku publicznych urzędów certyfikacji, ponieważ prywatny CA nie posiada infrastruktury odwołań: brak jest CRL oraz respondera OCSP, chyba że zostaną one samodzielnie wdrożone. W efekcie skompromitowany klucz końcowy pozostaje użyteczny aż do wygaśnięcia certyfikatu.

Przed dodaniem certyfikatu do magazynu zaufanych certyfikatów (trust store), należy zweryfikować wynik.

openssl x509 -noout -subject -issuer -serial -dates -in app.crt
openssl x509 -noout -ext subjectAltName -in app.crt

Pole issuer wskazuje teraz na CA, a nie na sam certyfikat końcowy. Pole SAN zawiera listę nazw, dla których certyfikat jest ważny; klient porównuje nazwę hosta wyłącznie z tą listą.

Weryfikacja przy użyciu jawnego -CAfile przed instalacją czegokolwiek

openssl verify -CAfile ca.crt app.crt
echo $?

To polecenie sprawdza jedną konkretną kwestię: czy app.crt tworzy łańcuch z certyfikatem w ca.crt? Nie informuje ono o tym, co jest zaufane dla bieżącej maszyny, ponieważ certyfikat główny został przekazany do OpenSSL bezpośrednio w wierszu poleceń. Błąd na tym etapie oznacza problem z samymi certyfikatami, dlatego należy go usunąć przed kontynuowaniem prac.

Teraz należy sprawdzić zaufanie systemu.

openssl verify app.crt
echo $?

Bez użycia -CAfile, OpenSSL korzysta z wbudowanego katalogu certyfikatów. openssl version -d wyświetla katalog bazowy używany przez kompilację, a w systemie Ubuntu katalog certs wskazuje na /etc/ssl/certs. Certyfikat główny nie znajduje się jeszcze w tym miejscu, więc weryfikacja kończy się niepowodzeniem: łańcuch dociera do wystawcy, którego nie ma w magazynie, a system nie ma gdzie szukać dalej. Należy zwrócić uwagę na kod wyjścia. To on zmieni się za dwa kroki.

Prawdziwy klient stanowi lepszy test niż openssl verify, ponieważ sprawdza zarówno nazwę hosta, jak i łańcuch certyfikatów. Należy udostępnić certyfikat i pobrać go.

openssl s_server -accept 8443 -cert app.crt -key app.key -www &
curl --resolve app.internal.example:8443:127.0.0.1 https://app.internal.example:8443/

--resolve kieruje połączenie na 127.0.0.1, jednocześnie żądając app.internal.example, dzięki czemu SAN jest zgodny, a jedyną otwartą kwestią pozostaje zaufanie. curl kończy działanie błędem i wyświetla przyczynę, dla której nie mógł zweryfikować łańcucha. Należy dodać -v, aby uzyskać więcej szczegółów. Serwer testowy powinien pozostać uruchomiony.

Instalacja certyfikatu głównego w /usr/local/share/ca-certificates

sudo cp ca.crt /usr/local/share/ca-certificates/example-internal-root.crt
sudo chmod 644 /usr/local/share/ca-certificates/example-internal-root.crt
sudo update-ca-certificates

Szczegóły decydujące o poprawności działania:

• Nazwa pliku musi kończyć się na .crt. Strona podręcznika update-ca-certificates wskazuje, że certyfikaty z rozszerzeniem .crt znajdujące się w /usr/local/share/ca-certificates są uwzględniane i automatycznie uznawane za zaufane. Plik o nazwie root.pem lub root.cer jest pomijany bez żadnego komunikatu.
• Zawartość musi być w formacie PEM, czyli blokiem base64 otoczonym liniami BEGIN CERTIFICATE oraz END CERTIFICATE. Plik DER zmieniony na .crt pozostaje plikiem binarnym i nie zostanie odczytany. Należy go przekonwertować za pomocą openssl x509 -inform DER -in ca.der -out ca.crt.
• W tym miejscu umieszcza się wyłącznie certyfikat główny. Klucz prywatny CA oraz certyfikat końcowy nie powinny znajdować się w magazynie zaufanych certyfikatów.

update-ca-certificates wyświetla liczbę dodanych i usuniętych certyfikatów. Jeśli nie dodano żadnego, przyczyną jest nieprawidłowe rozszerzenie lub format pliku.

Potwierdź zmianę z poziomu systemu, zamiast polegać wyłącznie na tym komunikacie.

ls -l /etc/ssl/certs/$(openssl x509 -noout -subject_hash -in /usr/local/share/ca-certificates/example-internal-root.crt).0
grep -c 'BEGIN CERTIFICATE' /etc/ssl/certs/ca-certificates.crt

Pierwsze polecenie tworzy nazwę pliku na podstawie skrótu podmiotu certyfikatu i wyświetla ją. update-ca-certificates utworzyło to dowiązanie symboliczne, które wskazuje na zainstalowany plik. Drugie polecenie zlicza certyfikaty w pojedynczym pliku zbiorczym. Uruchom je również przed instalacją, aby zaobserwować wzrost liczby o jeden.

Podczas kopiowania certyfikatu głównego na inne maszyny sprawdź, czy kopia dotarła w nienaruszonym stanie przed jej instalacją. Certyfikat główny jest plikiem, którego uszkodzenie niesie najpoważniejsze konsekwencje, dlatego traktuj go jak każdy inny plik, który należy zweryfikować sumą kontrolną przed użyciem.

Ponowna weryfikacja względem magazynu systemowego

openssl verify app.crt
echo $?
curl --resolve app.internal.example:8443:127.0.0.1 https://app.internal.example:8443/

Te same polecenia, te same pliki certyfikatów, inny wynik. W konfiguracji app.crt nic się nie zmieniło, a serwer jest tym samym, który uruchomiono wcześniej. Jedyną różnicą jest to, że certyfikat główny znajduje się teraz w magazynie, z którego korzystają klienci, dzięki czemu łańcuch jest kompletny. Jest to mechanizm, o którym warto pamiętać: weryfikacja polega na wyszukiwaniu wystawcy, któremu klient już ufa, a instalacja CA jest sposobem na umieszczenie wystawcy w miejscu, w którym klient prowadzi wyszukiwanie.

Zatrzymaj serwer testowy za pomocą kill %1.

Dlaczego /etc/ssl/certs nie jest miejscem na własne pliki

/etc/ssl/certs to wygenerowany wynik. update-ca-certificates wypełnia go dowiązaniami symbolicznymi do rzeczywistych plików certyfikatów i tworzy obok nich scalony pakiet /etc/ssl/certs/ca-certificates.crt.

Certyfikat skopiowany ręcznie do tego katalogu nie zostanie wykryty przez żaden proces. Mechanizm wyszukiwania katalogów OpenSSL otwiera tylko pliki nazwane zgodnie ze skrótem (hash) podmiotu certyfikatu, więc plik o nazwie myca.crt pozostaje dla niego niewidoczny. Narzędzie curl w systemie Ubuntu odczytuje plik pakietu, a pakiet ten jest przebudowywany z zarejestrowanych źródeł, więc ręcznie dodany plik również tam nie trafi. Uruchomienie update-ca-certificates --fresh powoduje usunięcie i ponowne utworzenie dowiązań symbolicznych w katalogu, co usuwa wszelkie ręcznie dodane dowiązania.

Druga część tego podziału to /usr/share/ca-certificates, który należy do pakietu ca-certificates i jest wymieniony w /etc/ca-certificates.conf. Aktualizacje pakietów nadpisują ten plik. /usr/local/share/ca-certificates to katalog zarezerwowany dla lokalnego administratora, dzięki czemu własny certyfikat CA przetrwa każdą aktualizację pakietu zarządzającego pozostałymi zasobami.

Które programy ignorują systemowy magazyn zaufanych certyfikatów

Instalacja certyfikatu głównego naprawia działanie każdego programu, który korzysta z OpenSSL lub odczytuje /etc/ssl/certs. Dotyczy to curl, wget, git, standardowego modułu ssl w języku Python oraz programów w języku Go, które w systemie Linux odczytują pliki systemowe. Środowiska uruchomieniowe dostarczające własną listę certyfikatów pozostają niepodatne na te zmiany; to właśnie one są najczęstszym źródłem nieporozumień po poprawnej instalacji.

• Node.js korzysta z wbudowanej listy. Należy wskazać mu certyfikat główny za pomocą NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/example-internal-root.crt, ustawionego w zmiennych środowiskowych przed uruchomieniem procesu, ponieważ Node odczytuje tę zmienną tylko raz podczas startu. Aktualne wydania Node posiadają również opcję odczytu magazynu systemowego; uruchom node --help | grep -i system-ca, aby sprawdzić, czy posiadana wersja ją wspiera.
• Biblioteka requests w języku Python korzysta z pakietu certifi. Ustaw REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt dla danego procesu lub przekaż verify="/etc/ssl/certs/ca-certificates.crt" do wywołania. pip wymaga --cert z tego samego powodu.
• Java odczytuje magazyn kluczy (keystore). W systemie Ubuntu pakiet ca-certificates-java instaluje skrypt typu hook w /etc/ca-certificates/update.d/, dzięki czemu update-ca-certificates odświeża również magazyn kluczy Java, jeśli pakiet ten jest obecny. W przeciwnym razie zaimportuj certyfikat główny za pomocą keytool -importcert.
• Firefox posiada własny magazyn i nigdy nie sprawdza /etc/ssl/certs. Importu należy dokonać poprzez ustawienia certyfikatów w przeglądarce. Chromium w systemie Linux odczytuje bazę danych NSS użytkownika, którą edytuje się za pomocą certutil z pakietu libnss3-tools.
• Kontenery posiadają własny system plików, więc magazyn hosta nie ma dla nich znaczenia. Skopiuj certyfikat główny do obrazu i uruchom update-ca-certificates podczas budowania. Uwzględnij to, jeśli Twoje usługi działają w ramach Docker Compose na VPS.

Jeśli program nadal odrzuca certyfikat po poprawnej instalacji, sprawdź, jakie pliki otwiera, zanim wprowadzisz jakiekolwiek inne zmiany. strace -f -e trace=openat <command> 2>&1 | grep -i cert działa bezpośrednio i pozwala uzyskać odpowiedź w jednym przebiegu.

Utrzymywanie użyteczności CA w czasie

Wystawienie nowego certyfikatu końcowego (leaf) wymaga ponownego wykonania kroku CSR oraz podpisywania przy użyciu tego samego pliku app.ext. Klienci nie muszą podejmować żadnych działań, ponieważ główny certyfikat (root), któremu ufają, nie uległ zmianie. Należy przechowywać plik ca.srl oraz każdy plik .ext w katalogu CA, aby kolejne wystawienie certyfikatu było powtórzeniem działającego polecenia, a nie odtwarzaniem procedury z pamięci.

Należy wykonać kopię zapasową ca.key oraz ca.crt w lokalizacji zewnętrznej, zachowując szyfrowanie. Utrata klucza uniemożliwia wystawianie nowych certyfikatów: konieczne staje się zbudowanie drugiego CA i zainstalowanie jego certyfikatu root w każdym miejscu, w którym znajdował się pierwszy. Należy prowadzić pisemną listę wszystkich maszyn i magazynów certyfikatów aplikacji, które otrzymały certyfikat root, ponieważ tylko taka lista umożliwia późniejszą rotację i usunięcie certyfikatów.

Gdy zbliża się termin wygaśnięcia certyfikatu root, należy wygenerować jego następcę z wyprzedzeniem i zainstalować oba certyfikaty root równolegle. Obecność dwóch certyfikatów root w magazynie jest dopuszczalna, a klient zaakceptuje każdy z nich. Należy wystawić certyfikaty końcowe ponownie w oparciu o nowy certyfikat root, a następnie usunąć stary, gdy żadne zasoby nie będą już od niego zależne.

Usuwanie urzędu certyfikacji (CA) z magazynu zaufanych certyfikatów

sudo rm /usr/local/share/ca-certificates/example-internal-root.crt
sudo update-ca-certificates --fresh

--fresh usuwa dowiązania symboliczne w /etc/ssl/certs i przebudowuje je na podstawie pozostałych źródeł, dzięki czemu usunięty certyfikat główny znika zarówno z katalogu, jak i z pakietu. Weryfikację usunięcia należy przeprowadzić w ten sam sposób, co weryfikację instalacji.

openssl verify app.crt
echo $?
grep -c 'BEGIN CERTIFICATE' /etc/ssl/certs/ca-certificates.crt
ls -l /etc/ssl/certs/$(openssl x509 -noout -subject_hash -in ~/ca/ca.crt).0

Weryfikacja ponownie kończy się niepowodzeniem, liczba certyfikatów wraca do stanu początkowego, a dowiązanie symboliczne oparte na skrócie (hash) zostaje usunięte.

To polecenie modyfikuje wyłącznie systemowy magazyn certyfikatów. Cofnięcie instalacji w pozostałych lokalizacjach wymaga ręcznych działań: wyczyszczenia NODE_EXTRA_CA_CERTS, usunięcia aliasu z każdego magazynu kluczy Java, usunięcia certyfikatu głównego z każdego profilu przeglądarki oraz przebudowania każdego obrazu kontenera, w którym certyfikat został osadzony. Usunięcie certyfikatu głównego nie unieważnia certyfikatów, które zostały przez niego podpisane. Pozostają one ważne na każdej maszynie, która nadal darzy go zaufaniem, co stanowi praktyczny powód, dla którego prywatny urząd CA wymaga prowadzenia pisemnej listy lokalizacji, w których zainstalowano certyfikat główny. Urząd CA, którego nie można w pełni wycofać, stanowi trwałą lukę w zabezpieczeniach, dlatego należy przetestować procedurę usuwania na jednej maszynie jeszcze w dniu konfiguracji, gdy lista lokalizacji jest krótka.

FAQ

Gdzie umieścić certyfikat CA w systemie Ubuntu?

W /usr/local/share/ca-certificates/, w pliku z rozszerzeniem .crt i zawartością w formacie PEM, a następnie należy wykonać sudo update-ca-certificates. Ten katalog jest zarezerwowany dla administratora lokalnego, dzięki czemu aktualizacje pakietów nie ingerują w jego zawartość. Katalog /usr/share/ca-certificates należy do pakietu ca-certificates, a /etc/ssl/certs jest generowany z obu powyższych, więc plik umieszczony w którymkolwiek z nich zostanie nadpisany lub zignorowany.

Dlaczego curl nadal odrzuca certyfikat po wykonaniu update-ca-certificates?

Należy sprawdzić przyczyny w podanej kolejności. Plik może nie mieć rozszerzenia .crt lub być w formacie DER zamiast PEM, przez co update-ca-certificates pominął go i nic nie dodał. Certyfikat może nie posiadać pola subjectAltName zgodnego z nazwą hosta, co stanowi błąd nazwy, a nie błąd zaufania; należy to zweryfikować za pomocą openssl x509 -noout -ext subjectAltName -in app.crt. Serwer może przesyłać tylko certyfikat końcowy, podczas gdy wymagany jest również certyfikat pośredni. Narzędzie curl może wskazywać na inny zestaw certyfikatów poprzez CURL_CA_BUNDLE lub --cacert. Ponadto długo działająca usługa wymaga restartu, ponieważ większość programów wczytuje magazyn zaufanych certyfikatów tylko raz, podczas uruchamiania.

Czy systemowy magazyn certyfikatów obejmuje Firefox, Chrome, Node i Java?

Nie. Narzędzia curl, wget, git, standardowy moduł ssl w języku Python oraz programy w języku Go odczytują pliki systemowe, więc działają one poprawnie natychmiast po wykonaniu update-ca-certificates. Przeglądarka Firefox posiada własny magazyn. Przeglądarka Chromium w systemie Linux korzysta z bazy danych NSS dla każdego użytkownika, edytowanej za pomocą certutil z pakietu libnss3-tools. Środowisko Node.js wymaga zmiennej NODE_EXTRA_CA_CERTS wskazującej na plik certyfikatu głównego. Java odczytuje magazyn kluczy, który update-ca-certificates odświeża tylko wtedy, gdy zainstalowany jest pakiet ca-certificates-java. Moduł requests w języku Python korzysta z certifi i wymaga REQUESTS_CA_BUNDLE.

Jak usunąć certyfikat CA z magazynu zaufanych certyfikatów w Ubuntu?

Należy usunąć plik z /usr/local/share/ca-certificates/ i wykonać sudo update-ca-certificates --fresh. Opcja --fresh usuwa dowiązania symboliczne w /etc/ssl/certs i tworzy je ponownie, dzięki czemu certyfikat zostaje usunięty zarówno z dowiązań skrótów, jak i z pakietu ca-certificates.crt w tym samym czasie. Należy potwierdzić usunięcie, wykonując openssl verify dla certyfikatu podpisanego przez to CA i sprawdzając kod wyjścia. Następnie należy powtórzyć proces usuwania w każdym innym magazynie, do którego certyfikat został dodany, ponieważ to polecenie nie wpływa na żaden z nich.

Czy mogę użyć prywatnego CA zamiast Let's Encrypt dla publicznej witryny?

Nie. Przeglądarka odwiedzającego nigdy nie widziała Twojego certyfikatu głównego, więc wyświetli ostrzeżenie na pełnym ekranie, a certyfikatu głównego nie można zainstalować na maszynach, nad którymi nie masz kontroli. Prywatne CA służy do obsługi nazw, które są rozpoznawane tylko przez Twoje własne maszyny oraz dla klientów, którymi zarządzasz. W przypadku każdej witryny odwiedzanej przez osoby trzecie należy uzyskać certyfikat od publicznego urzędu certyfikacji (CA).