Dlaczego nie mogę zweryfikować tego łańcucha certyfikatów?

16

Mam trzy certyfikaty w łańcuchu:

  • root.pem
  • pośredni.pem
  • john.pem

Gdy openssl x509 -in [filename] -text -nooutbadam je za pomocą , wyglądają dobrze, root.pem wygląda na podpisany przez siebie (Emitent == Temat), a Przedmiotem każdego certyfikatu jest, zgodnie z oczekiwaniami, Emitent kolejnego certyfikatu.

I rzeczywiście mogę zweryfikować łańcuch aż do certyfikatu pośredniego:

$ openssl verify -CAfile root.pem root.pem
root.pem: OK
$ openssl verify -CAfile root.pem intermediate.pem
intermediate.pem: OK

Jednak plik john.pem zawiedzie:

$ openssl verify -CAfile root.pem -CAfile intermediate.pem john.pem
john.pem: C = CL, [...redacted data...]
error 2 at 1 depth lookup:unable to get issuer certificate

Według mojej najlepszej wiedzy oznacza to, że openssl nie może znaleźć emitenta dla pliku pośredniego.pem. Co nie ma sensu, ponieważ root.pem jest rzeczywiście emitentem pośredniego.pem.

czego mi brakuje?

Edit: I początkowo pisał odpowiedź mówiąc, że root.pem i intermediate.pem powinny być łączone w jeden plik, a następnie powinno się użyć tego pliku jako parametr -CAfile. Jest to NIEPRAWIDŁOWE, ponieważ domyślnie ufa pośredni.pem, jak zauważa Johannes Pille . Przeczytaj link, który opublikował w mojej skasowanej odpowiedzi: https://mail.python.org/pipermail/cryptography-dev/2016-August/000676.html

certificate openssl Jong Bor
źródło
Usuń swoją odpowiedź, jest to niebezpieczna dezinformacja!
Johannes Pille,
1
@JohannesPille Gotowe, dziękuję za informację
Jong Bor
Wyrazy uznania za robienie tego i szybką reakcję.
Johannes Pille

Odpowiedzi:

14

Nie musisz zbierać dwóch certyfikatów razem, aby je zweryfikować.

Jeśli masz następujące trzy certyfikaty:

  • root.pem - przechowuje samopodpisany certyfikat.
  • pośrednie.pem - przechowuje certyfikat podpisany przez root.pem
  • john.pem - przechowuje certyfikat podpisany przez intermed.pem

I ufasz tylko root.pem, a następnie zweryfikujesz john.pemza pomocą następującego polecenia:

openssl verify -CAfile root.pem -untrusted intermediate.pem john.pem

Gdybyś miał wiele półproduktów, mógłbyś po prostu łańcuch -untrusted intermediate2.pem -untrusted intermediate3.pem ...

antiduh
źródło
To. To jedyna poprawna odpowiedź.
Johannes Pille,
Pomyślałem, że gdybym miał zarówno Pośredni, jak i Główny certyfikat CA w pakiecie, opensslpodniosłbym je i zweryfikowałby certyfikaty. Czy istnieje powód, aby tak się działo? Na przykład osoba, która podpisała certyfikat użytkownika, nie podpisała go za pomocą Pośredniego, ale rootem, czy coś takiego?
FilBot3
Ostatnie zdanie tej odpowiedzi jest nieprawidłowe. Jeśli masz wiele półproduktów, musisz połączyć je w jeden plik pośredni, a następnie użyć untrustedflagi raz. Wielokrotne użycie niezaufanej flagi nie działa.
AjaxLeung
1
@AjaxLeung - działa wiele -untrustedopcji (w dowolnej kolejności) lub jedna -untrustedopcja wskazująca na pakiet produktów pośrednich (połączonych w dowolnej kolejności). Dotyczy to wersji OpenSSL 1.1.1c na Ubuntu.
garethTheRed
Tak, pomyliłem się. Myślę, że w momencie pisania komentarza po prostu nie używałem odpowiednich plików.
AjaxLeung
3

To, co powiedział @antiduh, działa tylko dla mnie w przypadku pojedynczego certyfikatu pośredniego. Dodanie więcej niż jednego -untrusted intermediate.pempolecenia wydaje się nie działać. Nie jestem pewien, czy jest to związane z konkretną wersją openssl.

Zgodnie z dokumentem openssl: [ https://linux.die.net/man/1/verify]

plik niezaufany

Plik niezaufanych certyfikatów. Plik powinien zawierać wiele certyfikatów

W moim przypadku mam łańcuch taki jak: root.pem -> intermediate1.pem -> intermediate2.pem -> john.pem

przez cat intermed1.pem i intermed2.pem do jednego pliku pośredniego łańcucha.pem, a następnie uruchom openssl verify -CAfile root.pem -untrusted intermediate-chain.pem john.pemdziała dla mnie.

Wygląda też na to, że rozszerzenie in należy ustawić basicConstraints = CA:trueinaczej, w przeciwnym razie nadal napotyka błąd weryfikacji raportu otwarcia.

Yang Xu
źródło