Odkąd podałeś tag, ssl-certificate, zakładam, że potrzebujesz takiego sprawdzania poprawności podczas połączenia SSL w przypadku sprawdzania poprawności certyfikatu serwera lub sprawdzania poprawności certyfikatu klienta.
Prosty sposób na osiągnięcie tego poprzez ustawienie wywołania zwrotnego weryfikacyjnego za pomocą OpenSSL API SSL_CTX_set_verify.
Istotą jest to, że to wywołanie zwrotne będzie wywoływane za każdym razem, gdy napotkany zostanie błąd podczas sprawdzania poprawności certyfikatu, więc w twoim przypadku, gdy root nie może zostać znaleziony, to wywołanie zwrotne zostanie wywołane z błędem X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT. Będziesz mieć również dostęp do X509_STORE_CTX *, z którego możesz uzyskać szczegóły certyfikatów zweryfikowanych do tej pory. Za pomocą tego mechanizmu można zaimplementować odpowiednią logikę w kodzie, aby sprawdzić, czy certyfikaty jednostek końcowych i pośrednich urzędów certyfikacji są poprawne, a jeśli okaże się, że wszystko jest w porządku, można odnieść sukces z wywołania zwrotnego, które zasygnalizuje serwerowi OpenSSL kontynuowanie sprawdzania poprawności. bez sprawdzania.
Więcej szczegółów z dokumentacji OpenSSL:
Funkcja verify_callback służy do kontrolowania zachowania, gdy flaga SSL_VERIFY_PEER jest ustawiony. Musi być dostarczony przez aplikację i otrzymuje dwa argumenty: preverify_ok wskazuje, czy weryfikacja danego certyfikatu została przyjęta (preverify_ok = 1) czy nie (preverify_ok = 0). x509_ctx jest wskaźnikiem do pełnego kontekstu używanego do weryfikacji łańcucha certyfikatów.
Łańcuch certyfikatów jest sprawdzany począwszy od najgłębszego poziomu zagnieżdżenia (głównego certyfikatu CA) i pracujący w górę do certyfikatu równorzędnego. Na każdym poziomie sprawdzane są atrybuty sygnatur i wystawców. Po wykryciu błędu weryfikacji numer błędu jest przechowywany w formacie x509_ctx, a funkcja sprawdzania_obowiązania zwrotnego jest wywoływana z preverify_ok = 0. Dzięki zastosowaniu funkcji X509_CTX_store_ * verify_callback może zlokalizować dany certyfikat i wykonać dodatkowe kroki (zobacz PRZYKŁADY). Jeśli nie zostanie znaleziony błąd dla certyfikatu, funkcja verify_callback jest wywoływana z preverify_ok = 1 przed przejściem do następnego poziomu.
Zwracana wartość verify_callback kontroluje strategię dalszego procesu weryfikacji. Jeśli funkcja verify_callback zwróci 0, proces weryfikacji zostanie natychmiast zatrzymany z błędem "weryfikacja nie powiodła się". Jeśli ustawiono SSL_VERIFY_PEER, alert o niepowodzeniu weryfikacji jest wysyłany do węzła równorzędnego, a uzgadnianie TLS/SSL jest kończone. Jeśli verify_callback zwróci 1, proces weryfikacji będzie kontynuowany. Jeśli funkcja verify_callback zawsze zwróci wartość 1, uzgadnianie TLS/SSL nie zostanie zakończone w odniesieniu do niepowodzeń weryfikacji i połączenie zostanie nawiązane. Proces wywołujący może jednak pobrać kod błędu z ostatniego błędu weryfikacji przy użyciu SSL_get_verify_result (3) lub przez utrzymywanie własnego magazynu błędów zarządzanego przez funkcję verify_callback.
Jeśli nie określono opcji verify_callback, zostanie użyte domyślne wywołanie zwrotne.Jego wartość zwracana jest identyczna z wartością preverify_ok, więc każda awaria weryfikacji spowoduje zakończenie uzgadniania TLS/SSL z komunikatem alertu, jeśli ustawiono SSL_VERIFY_PEER.
Może być pomocna: http://stackoverflow.com/questions/13295585/openssl-certificate-verification-on-linux – JSuar
2Balamurugan: Przykro mi. Myliłem się w mojej odpowiedzi, którą napisałem. Usunąłem to. Sprawdziłem parametry "openssl verify" i wygląda na to, że wymaga to całego łańcucha certyfikatów. –
BTW. Pytanie. Dlaczego nie można uzyskać certyfikatu głównego w trybie offline i można go przekonwertować na certyfikat CA1 (aby umożliwić sprawdzenie, czy działa poprawnie). Jaki jest przypadek testowy, gdy masz dostęp do certyfikatu CA1, ale nie masz dostępu do certyfikatu głównego? –