Comment configurer la configuration de base Jersey/Grizzly 2.21 de démarrage SSL

J'essaie d'obtenir un serveur Grizzly très basique pour permettre des connexions SSL (HTTPS) unidirectionnelles pour accéder aux services REST de jax-rs. Finalement, je veux une sécurité SSL bidirectionnelle. J'ai passé en revue de nombreux exemples et je ne peux rien obtenir pour travailler. Je continue de courir dans une erreur SSL Handshake. Clairement, je dois faire quelque chose de stupide. Toute aide est appréciée.Comment configurer la configuration de base Jersey/Grizzly 2.21 de démarrage SSL

Voici mon code pour démarrer mon serveur Grizzly embarqué en utilisant les classes wrapper Jersey:

public static HttpServer startHttpsServer(URI listenerURI) throws IOException { 
    ResourceConfig resourceConfig = new ResourceConfig().packages("ws.argo.experiment.ssl"); 

    // First I tried this configuration using the certs from the Jersey sample code 
    // Grizzly ssl configuration 
    SSLContextConfigurator sslContext = new SSLContextConfigurator(); 

    // set up security context 
    sslContext.setKeyStoreFile("./src/main/resources/keystore_server"); // contains server keypair 
    sslContext.setKeyStorePass("asdfgh"); 
    sslContext.setTrustStoreFile("./src/main/resources/truststore_server"); // contains client certificate 
    sslContext.setTrustStorePass("asdfgh"); 

    // Then I tried just using a default config - didn't work either 
    // sslContext = SSLContextConfigurator.DEFAULT_CONFIG; 


    if (!sslContext.validateConfiguration(true)) { 
    LOGGER.severe("Context is not valid"); 

    } 

    LOGGER.finer("Starting Jersey-Grizzly2 JAX-RS secure server..."); 
    HttpServer httpServer; //= GrizzlyHttpServerFactory.createHttpServer(listenerURI, resourceConfig, false); 


    httpServer= GrizzlyHttpServerFactory.createHttpServer(
     listenerURI, 
     resourceConfig, 
     true, 
     new SSLEngineConfigurator(sslContext).setClientMode(false).setNeedClientAuth(false) 
    ); 



    httpServer.getServerConfiguration().setName("Test HTTPS Server"); 
    httpServer.start(); 
    LOGGER.info("Started Jersey-Grizzly2 JAX-RS secure server."); 

    return httpServer; 
}

J'ai aussi essayé remplacé SSLEngineConfigurator (SSLContext) .setClientMode (false) .setNeedClientAuth (false) avec null pour voir si Cela aiderait. Nan.

je reçois toujours l'erreur suivante:

grizzly-nio-kernel(3) SelectorRunner, fatal error: 40: no cipher suites in common 
javax.net.ssl.SSLHandshakeException: no cipher suites in common 
%% Invalidated: [Session-2, SSL_NULL_WITH_NULL_NULL] 
grizzly-nio-kernel(3) SelectorRunner, SEND TLSv1.2 ALERT: fatal, description = handshake_failure 
grizzly-nio-kernel(3) SelectorRunner, WRITE: TLSv1.2 Alert, length = 2 
grizzly-nio-kernel(3) SelectorRunner, fatal: engine already closed. Rethrowing javax.net.ssl.SSLHandshakeException: no cipher suites in common

Source

2015-11-20 jmsimpson68

Vous n'avez besoin que du certificat client dans le magasin de confiance du serveur pour le protocole SSL mutuel (bidirectionnel). Si le certificat du serveur est auto-signé, vous devez ajouter le certificat du serveur au magasin de confiance du client. –

Jetez un coup d'œil à [cet exemple] (https://github.com/jersey/jersey/tree/master/ examples/https-clientserver-grizzly) –

@peetskillet - c'est l'exemple avec lequel j'ai commencé. La seule différence est que je n'utilise pas la configuration jersey-container-grizzly2-servlet. Juste en utilisant la version régulière de jersey-container-grizzly2-http comme une dépendance. Je ne pense pas que cela ferait une différence. – jmsimpson68

Je l'ai vu ce type de problème poignée de main venir dans d'autres messages tout en essayant de lancer cette question à la terre. Dans tous ces messages de prise de contact, l'algorithme de clé de serveur n'a jamais été discuté - j'aurais aimé que cela ait été le cas. Cela m'aurait sauvé quelques heures. Le problème à l'origine des erreurs ci-dessus découlait de l'hypothèse que les fichiers de clés créés dans le cadre du projet exemple Jersey fonctionneraient. La clé du serveur était le problème.

Les certificats de serveur d'exemple sont générés à l'aide de l'algorithme DSA. Apparemment c'est un problème.

J'ai recréé les clés du serveur en utilisant un algorithme RSA et une force de 2048 bits. J'ai redémarré le serveur et tout a commencé à fonctionner comme on pouvait s'y attendre. L'erreur était que j'ai supposé que les clés "d'échantillon" fonctionneraient. Oops.

Source

2015-11-20 19:11:46 jmsimpson68

Pour ajouter au commentaire JMS, sa réponse résout mon problème. Voici la commande que j'ai utilisée pour générer le certificat RSA.

keytool -genkey -keystore ./keystore_client -alias clientKey -keyalg RSA -keypass changeit -storepass changeit -dname "CN=Client, OU=Jersey, O=changeit, L=KL, ST=SEL, C=MY" 
keytool -export -alias clientKey -storepass changeit -keystore ./keystore_client -file ./client.cert 
keytool -import -alias clientCert -file ./client.cert -storepass changeit -keystore ./truststore_server 


keytool -genkey -keystore ./keystore_server -alias serverKey -keyalg RSA -keyalg RSA -keypass changeit -storepass changeit -dname "CN=changeit, OU=Jersey, O=changeit, L=KL, ST=SEL, C=MY" 
keytool -export -alias serverKey -storepass changeit -keystore ./keystore_server -file ./server.cert 
keytool -import -alias serverCert -file ./server.cert -storepass changeit -keystore ./truststore_client

Source

2016-05-12 01:17:08

Comment configurer la configuration de base Jersey/Grizzly 2.21 de démarrage SSL

Répondre

Questions connexes