OpenVPN: certyfikat z podpisem własnym w łańcuchu


9

Próbuję bardzo bezskutecznie używać TunnelBlick(klienta OpenVPN 2.2.1 systemu OS / X, który jest dobrze znany) do łączenia się za pomocą certyfikatów. Oto komunikat o błędzie (odkażony), który otrzymuję:

11.01.2012 11:18:26 TLS: Pakiet początkowy od **. **. **. **: 1194, sid = 17a4a801 5012e004
11.01.2012 11:18:26 BŁĄD WERYFIKACJI: głębokość = 1, błąd = samopodpisany certyfikat w łańcuchu certyfikatów: / C = US / ST = ** / L = ** / O = ** / CN = ** / emailAddress = **
11.01.2012 11:18:26 TLS_ERROR: BIO odczytał tls_read_plaintext błąd: błąd: 14090086: Procedury SSL: SSL3_GET_SERVER_CERTIFICATE: weryfikacja certyfikatu nie powiodła się
2012-01-11 11:18:26 Błąd TLS: Obiekt TLS -> błąd przychodzącego odczytu tekstu jawnego
2012-01-11 11:18:26 Błąd TLS: Uzgadnianie TLS nie powiodło się
2012-01-11 11:18:26 TCP / UDP: Zamykanie gniazda

A teraz pocieranie. I generowane CSR się do żądania tego certyfikatu, używając ca.crt pliku dostarczonego mi przez drugą stronę (w rzeczywistości zrobili to dwa razy, żeby się upewnić).

Odpowiednie wpisy w konfiguracji klienta to:

ca   ca.crt
cert my.crt
key  my.key

a ponadto ... Mogę zweryfikować klucze w ten sposób:

openssl sprawdź -CAfile ca.crt my.crt 
my.crt: OK

Okej, więc teraz jestem całkowicie zdziwiony i zakłopotany. W tym momencie wiem, że CSR i klucz zostały wygenerowane przy użyciu właściwego CSR. W rzeczywistości oto polecenie, które to zrobiło:

openssl req -newkey rsa:2048 -new -out my.csr -keyout my.key

Wiedziałem również, aby to zrobić:

openssl x509 -subject -issuer -noout -in ca.crt

...

(migać!)

Właśnie to znalazłem ?

Wynik działania tego polecenia wygląda następująco: (nieco zmodyfikowany)

subject = / C = US / ST = VA / L = ** / O = ** / CN = ** CA / emailAddress = **
emitent = (to samo)

podczas gdy w komunikacie o błędzie z OpenVPN, ST = nie jest dokładnie taki sam:

BŁĄD WERYFIKACJI: głębia = 1, błąd = samopodpisany certyfikat w łańcuchu certyfikatów: / C = US / ST = Virginia / L = ** / O = ** / CN = ** / emailAddress = **

„VA” nie jest dokładnie równe „Virginia”.


2
Spróbuj openssl s_client -connect host:port -showcertsi porównaj odcisk palca otrzymanego certyfikatu z openssl x509 -noout -text -in ca.crt.
Shane Madden

Odpowiedzi:


7

Tylko po to, aby całkowicie zamknąć ten wątek: to rzeczywiście był problem. „Ca.crt”, które otrzymałem („Virginia”), NIE BYŁO faktycznie tym, którego używał mój kolega („VA”), i żadne z nas tego nie zauważyło.

Więc ... w zasadzie (i wyłącznie w kategoriach laika) VPN próbował przejść się po łańcuchu autorytetów, szukając przepustki, której spodziewał się znaleźć, ale nigdy tego nie zrobił (ponieważ jej nie było).

Jest to jeden z tych wspaniałych komunikatów, z których systemy kryptograficzne są tak dobrze znane: całkowicie dokładne, a jednak całkowicie tajemnicze dla niewtajemniczonych. (I, szczerze mówiąc, systemy kryptograficzne nie lubią ujawniać informacji o niczym, ponieważ zakładają, że osoba, z którą rozmawiają, to zła Ewa , a nie miła Alice lub Bob.)


Szczerze mówiąc, nie jestem przekonany, że ma to coś wspólnego z łańcuchem urzędów certyfikacji, a bardziej z faktem, że był to przede wszystkim inny urząd certyfikacji, a zatem automatycznie niezaufany. OpenSSL nie musi dużo spacerować. Może jednak o to ci chodziło.
rodzic
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.