Tengo un JBoss AS7 que se conecta a AWS y específicamente a S3 sobre AWS SDK para Java, tengo las claves secretas y de acceso, y todo funciona bien. Uso el S3 para compartir varios archivos.
La fuente de datos de JBoss se conecta a AWS RDS. Habilité el cifrado SSL para la fuente de datos: tengo rds-ca-2019-root.pem en mi almacén de confianza configurado en mi standalone.xml, y mi fuente de datos RDS se conecta y verifica el SSL sin problemas. Sin embargo, cuando intento conectarme a S3 a través del SDK (cuando el almacén de confianza con el certificado RDS está habilitado), obtengo la siguiente excepción:
Caused by: com.amazonaws.SdkClientException: Unable to execute HTTP request: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Entonces, no hay un almacén de confianza habilitado: puedo conectarme a S3 a través de SDK sin problemas. Cuando habilito el almacén de confianza con el certificado RDS: mi conexión SDK -> S3 se interrumpe.
No puedo averiguar qué certificado necesito agregar al almacén de confianza para que el SDK pueda funcionar, ¿o necesito configurar el SDK para usar TLS de alguna manera?
La respuesta de Ognjen me ayudó a solucionar este problema. Tuve el mismo problema y el problema era que el SDK de AWS estaba usando el almacén de confianza personalizado que construí para la conexión RDS. He especificado el almacén de confianza personalizado configurando el parámetro javax.net.ssl.trustStore explícitamente.
La solución que apliqué: usé el script en esta documentación para importar rds-combined-ca-bundle.pem a $JAVA_HOME/lib/security/cacerts (puede encontrar este archivo cacerts dentro de la carpeta jre/lib/security si tienes el JDK instalado). Luego eliminé la configuración javax.net.ssl.trustStore que tenía. Luego, Java comenzó a usar el archivo cacerts predeterminado y ahora todo está bien.
La contraseña predeterminada del almacén de confianza predeterminado de Java es chageit .
Así que descubrí qué estaba mal: no tener ningún tipo de almacén de confianza personalizado definido para mi jboss significaba que AWS SDK extrajo el almacén de confianza de cacerts normal de $JAVA_HOME/lib/security/cacerts . Definir mi propio almacén de confianza (que carecía de todos los certificados del almacén de confianza de cacerts) significaba que AWS SDK no tenía dónde obtener los certificados regulares.
Entonces, para resolverlo: importé mi rds-ca-2019-root.pem en el archivo cacerts mencionado anteriormente y lo vinculé como el almacén de confianza de mi servidor en mi standalone.xml.
Ognjen y Asanka proponen usar el mismo almacén de confianza para toda la aplicación (o servidor de aplicaciones) que no es adecuado en algunos casos. Pero AWS Java SDK proporciona ApacheHttpClientConfig a través de ClientConfiguration para afectar al cliente Apache HTTP, por ejemplo:
import com.amazonaws.ApacheHttpClientConfig; import com.amazonaws.ClientConfiguration; import com.amazonaws.http.conn.ssl.SdkTLSSocketFactory; import com.amazonaws.services.s3.AmazonS3; import com.amazonaws.services.s3.AmazonS3ClientBuilder; import javax.net.ssl.HostnameVerifier; import javax.net.ssl.SSLContext; import org.apache.http.conn.socket.ConnectionSocketFactory; SSLContext myContext = ... HostnameVerifier myVerifier = ... ConnectionSocketFactory factory = new SdkTLSSocketFactory(myContext, myVerifier); ClientConfiguration clientConfiguration = new ClientConfiguration(); clientConfiguration.getApacheHttpClientConfig().setSslSocketFactory(factory); AmazonS3 s3client = AmazonS3ClientBuilder.standard() .withClientConfiguration(clientConfiguration) .build();Editar: consulte también la pregunta StackOverflow # 47913449 .