Błąd podczas https otwarcia URL: keyCertSign bit nie jest ustawiony

Wołam zdalnego https URL z następującego kodu:Błąd podczas https otwarcia URL: keyCertSign bit nie jest ustawiony

def inputStream = new URL("https://somewebsite.com").openStream()

Działa to doskonale na moim komputerze lokalnym, ale gdy wdrożyć do serwera, I Pojawia się następujący wyjątek:

java.security.cert.CertPathValidatorException: CA key usage check failed: keyCertSign bit is not set

Co jest przyczyną tego błędu, a co może stanowić to pracę na jednej maszynie, a nie inny?

UPDATE

biegnę serwer Ubuntu w produkcji i rozwoju na Mac lokalnie. Witryna Próbuję dostępu (nazwijmy go peopleware.com) posiada następujące informacje certyfikatu:

AddTrust zewnętrzny urząd certyfikacji
UTN-USERFirst-Hardware
peopleware.com

próbowałem zapisywania plików cer z mojej przeglądarce i instalowania ich w magazynie kluczy w pliku/etc/ssl/certyfikatów/Java/Castore

Źródło

2012-04-22 Mike Sickler

Najprawdopodobniej twój serwer nie ma zainstalowanego właściwego certyfikatu głównego, więc nie może zweryfikować, czy certyfikat SSL, który dana witryna zapewnia, jest ważny. –

Dzięki - Kupiłem certyfikat SSL i zainstalowałem go na tym serwerze. Czy to może mieć z tym coś wspólnego? Czy to nie ma związku? –

To zależy, czy ten błąd pojawia się podczas łączenia się z serwera z innym komputerem, czy z innego komputera na serwer? –

Zakładam, że mówisz o tym certyfikacie z UTN-USERFi RST-Hardware:

w wersji czytelnej dla człowieka:

Version: 3 (0x2) 
Serial Number: 
    44:be:0c:8b:50:00:24:b4:11:d3:36:2a:fe:65:0a:fd 
Signature Algorithm: sha1WithRSAEncryption 
Issuer: C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Hardware 
Validity 
    Not Before: Jul 9 18:10:42 1999 GMT 
    Not After : Jul 9 18:19:22 2019 GMT 
Subject: C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Hardware 
Subject Public Key Info: 
    [...] 
X509v3 extensions: 
    X509v3 Key Usage: 
     Digital Signature, Non Repudiation, Certificate Sign, CRL Sign 
    X509v3 Basic Constraints: critical 
     CA:TRUE 
    X509v3 Subject Key Identifier: 
     A1:72:5F:26:1B:28:98:43:95:5D:07:37:D5:85:96:9D:4B:D2:C3:45 
    X509v3 CRL Distribution Points: 

     Full Name: 
      URI:http://crl.usertrust.com/UTN-USERFirst-Hardware.crl 

    X509v3 Extended Key Usage: 
     TLS Web Server Authentication, IPSec End System, IPSec Tunnel, IPSec User

Zasadniczo mamy tu certyfikat CA z obu X509v3 Key Usage i X509v3 Extended Key Usage.

Jednak RFC 3280 says the following about the extended key usage extension:

W ogóle, to rozszerzenie pojawi się na końcowej podmiotu certyfikatów.

To nie rozpocznie się zbyt dobrze na cert CA, ale później, ta sama sekcja również mówi w ten sposób:

Jeśli certyfikat zawiera zarówno klucz przedłużenie użytkowania oraz rozszerzoną użycia klucza rozszerzenie, wtedy oba rozszerzenia MUSZĄ być przetwarzane niezależnie, a certyfikat MUSI być używany tylko do celu zgodny z obydwoma rozszerzeniami. Jeśli nie ma celu zgodnego z z obydwoma rozszerzeniami, certyfikat NIE MOŻE być używany dla żadnego celu .

Jedynym rozszerzony klucz rozszerzenie wykorzystanie w tym cert, który jest w tym dokumencie RFC jest TLS Web Server Authentication:

id-kp-serverAuth    OBJECT IDENTIFIER ::= { id-kp 1 } 
    -- TLS WWW server authentication 
    -- Key usage bits that may be consistent: digitalSignature, 
    -- keyEncipherment or keyAgreement

Oczywiście, nie jest to zgodne z keyCertSign, który, zgodnie z RFC 3280 (i RFC 5280). (Wątpię też, czy którekolwiek z rozszerzeń IPSec jest kompatybilne z keyCertSign). Dzięki temu ten certyfikat jest bezużyteczny przy wydawaniu certyfikatów (niezbyt użyteczne dla certyfikatu CA).

Chciałbym skontaktować się ze stroną internetową za pomocą tego certyfikatu, aby poprosić ich o skontaktowanie się ze swoim urzędem certyfikacji (UTN-USERFirst-Hardware, podobno Comodo) i poproszenie ich o naprawienie tego. Muszę powiedzieć, że nie wygląda dobrze, gdy pochodzą od ludzi, którzy zarabiają pieniądze na tych RFC.

Oczywiście może to chwilę potrwać i nie rozwiąże to Twojego bezpośredniego problemu.

Wydaje mi się, że widziałem tę DNę podmiotu (UTN-USERFirst-Hardware) w innych pośrednich certyfikatach CA, więc powyższy może nie być tym, którego używasz.

Co możesz zrobić (pod warunkiem, że mimo tych problemów można ręcznie zweryfikować certyfikat serwera), należy użyć SSLContext i TrustManager specjalnie ograniczonego do używania tego samego certyfikatu dla tego połączenia. Może to uniemożliwić algorytmowi ścieżki certyfikacji, aby spróbować znaleźć certyfikat wystawcy i wpaść w ten problem.

EDIT:

Oto więcej szczegółów na temat tego obejścia (które nadal powinny zachować swoje połączenie bezpieczne).

Łącz się z Firefoksem na tej stronie.
kliknąć na niebieski/zielony pasek i wybierz opcję „Więcej informacji ...”
Zabezpieczenia -> Wyświetl certyfikat -> Szczegóły
Wybierz certyfikat serwera z listy na górze i wybierz „Eksportuj ... "
Gdzieś tam jest plik PEM.

Zastosowanie keytool aby utworzyć nowy kluczy (wybierz zaufać, że certyfikat i wybrać sensownego hasło):

keytool -importcert -keystore example.jks -file example.pem

Następnie użyj tego kodu Java, które nie powinno być zbyt trudne do portu Groovy:

TrustManagerFactory tmf = TrustManagerFactory 
    .getInstance(TrustManagerFactory.getDefaultAlgorithm()); 
KeyStore ks = KeyStore.getInstance("JKS"); 
FileInputStream fis = new FileInputStream("/.../example.jks"); 
ks.load(fis, null); 
// or ks.load(fis, "thepassword".toCharArray()); 
fis.close(); 

tmf.init(ks); 

SSLContext sslContext = SSLContext.getInstance("TLS"); 
sslContext.init(null, tmf.getTrustManagers(), null); 

URL url = new URL("https://somewebsite.com"); 
HttpsURLConnection conn = (HttpsURLConnection) url.openConnection(); 
conn.setSSLSocketFactory(sslContext.getSocketFactory()); 

InputStream is = conn.getInputStream();

Źródło

2012-04-24 18:10:52 Bruno

Błąd podczas https otwarcia URL: keyCertSign bit nie jest ustawiony

Odpowiedz

Powiązane problemy