error al https apertura URL: poco keyCertSign no se establece

Estoy llamando a una dirección URL https remoto con el siguiente código:error al https apertura URL: poco keyCertSign no se establece

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

Esto funciona muy bien en mi máquina local, pero cuando despliego al servidor, me obtener la siguiente excepción:

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

¿Cuál es la causa de este error, y lo que podría dar cuenta de que trabajar en una máquina y no otro?

ACTUALIZACIÓN

Estoy corriendo un servidor de Ubuntu en la producción y el desarrollo en un Mac localmente. El sitio que estoy tratando de acceso (vamos a llamarlo peopleware.com) tiene la siguiente información del certificado:

AddTrust externa raíz de CA
UTN-USERFirst en hardware
peopleware.com

he tratado de guardar los archivos .cer de mi navegador y la instalación de ellos en el almacén de claves en/etc/ssl/certs/java/castore

Fuente

2012-04-22 Mike Sickler

Es muy probable que su servidor no tenga instalado el certificado raíz correcto, por lo que no puede verificar que el certificado SSL que le proporciona el sitio sea válido. –

Gracias. Compré un certificado SSL y lo instalé en este servidor. ¿Podría eso tener algo que ver con eso? ¿O no está relacionado? –

Depende, ¿aparece este error al conectarse desde el servidor a otra máquina o desde otra máquina al servidor? –

estoy asumiendo que usted está hablando de este certificado de UTN-USERFi primero en hardware:

En una versión legible:

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

Esencialmente, tenemos aquí un certificado de CA con tanto X509v3 Key Usage y X509v3 Extended Key Usage.

Sin embargo, RFC 3280 says the following about the extended key usage extension:

En general, esta extensión aparecerá sólo en la entidad final certificados.

Esto no se inicia demasiado bien para un CERT CA, pero más tarde, la misma sección también dice esto:

Si un certificado contiene una extensión de uso de clave y un extendido uso de la clave extensión, entonces ambas extensiones DEBEN procesarse independientemente y el certificado DEBE ser usado solo para un propósito consistente con ambas extensiones. Si no hay un propósito consistente con ambas extensiones, entonces el certificado NO DEBE utilizarse con ningún propósito .

La única extensión de uso de clave extendida en este certificado que se encuentra en este RFC es TLS autenticación de servidor Web:

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

Por supuesto, esto no es consistente con keyCertSign, que, de acuerdo con RFC 3280 (y RFC 5280). (También dudo que cualquiera de las extensiones IPSec sea compatible con keyCertSign). Esto hace que este certificado sea inútil para emitir certificados (no es muy útil para un certificado de CA).

Me pondría en contacto con el sitio web usando este certificado para pedirles que se pongan en contacto con su CA (UTN-USERFirst-Hardware, aparentemente Comodo) y les pido que solucionen esto. Debo decir que no se ve bien proveniente de personas que hacen su dinero en la parte posterior de estos RFC.

Por supuesto, esto podría demorar un tiempo y no resolvería su problema inmediato.

Creo que he visto este DN de sujeto (UTN-USERFirst-Hardware) en otros certificados de CA intermedios, por lo que el de arriba podría no ser el que estás usando.

Lo que podría hacer (siempre que pueda verificar el certificado del servidor manualmente a pesar de estos problemas) es usar un SSLContext y un TrustManager específicamente limitado para usar ese mismo certificado, para esta conexión. Esto podría evitar que el algoritmo de ruta de certificación intente encontrar el certificado de emisor y caiga en este problema.

EDIT:

Aquí hay más detalles sobre esta solución (que aún debe mantener su conexión segura).

Conéctese con Firefox a este sitio web.
Haga clic en la barra azul/verde y selecciona 'Más información ...'
Seguridad -> Ver certificado -> Detalles
Elige el certificado del servidor de la lista en la parte superior y selecciona 'Exportar ... '
Lo mismo que el archivo PEM en alguna parte.

Uso keytool para crear un nuevo almacén de claves (elegir confiar en el certificado y elegir una contraseña sensible):

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

A continuación, utilice el código de Java, que no debería ser demasiado difícil de puerto para 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();

Fuente

2012-04-24 18:10:52 Bruno

error al https apertura URL: poco keyCertSign no se establece

Respuesta

Cuestiones relacionadas