J'aimerais utiliser JNLP pour connecter des esclaves Jenkins au maître Jenkins. Le maître s'exécute derrière un proxy SSL nginx configuré conformément à la documentation officielle . Au-delà de cette documentation, je rencontre des problèmes liés aux certificats.
Actuellement, je peux faire en sorte que la connexion principale de l'esclave sans tête JNLP fonctionne uniquement avec une connexion HTTP non sécurisée, mais pas avec HTTPS (bien que mon tableau de bord jenkins fonctionne généralement). J'utilise un certificat auto-signé, signé par mon propre certificat CA personnalisé (basé sur OpenSSL x509).
Alors, comment puis-je dire au binaire java de mon esclave de faire confiance à mon certificat SSL CA? J'ai essayé ça.
# add CA certificate to key store
$ keytool -import -file /usr/local/share/ca-certificates/my_ca.crt -alias my_ca -storepass mypassword
# try to reference keystore to JNLP headless call
$ java -Djavax.net.ssl.keyStorePassword=mypassword -Djavax.net.ssl.keyStore=/home/myuser/.keystore -jar slave.jar -jnlpUrl https://proxied-jenkins.example.com/computer/testslave/slave-agent.jnlp
En réalité, JAVA ne semble pas rechercher le certificat dans le fichier de clés fourni. Quelle est mon erreur ici?
MODIFIER
Un problème similaire / même se produit lors de l'utilisation de jenkins cli. D'après cela , maintenant, je suppose que cela n'a rien à voir avec la confiance en mon certificat, car je ne peux pas voir unjavax.net.ssl.SSLHandshakeException
Je viens de recevoir une réinitialisation de la connexion
Failing to obtain https://proxied-jenkins.example.com/computer/testslave/slave-agent.jnlp
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
at sun.security.ssl.InputRecord.read(InputRecord.java:480)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:934)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1359)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1343)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153)
at hudson.remoting.Launcher.parseJnlpArguments(Launcher.java:269)
at hudson.remoting.Launcher.run(Launcher.java:219)
at hudson.remoting.Launcher.main(Launcher.java:192)
.. donc je suppose un problème de configuration avec mon proxy. J'ai pris la configuration de la configuration du proxy inverse et ajouté la configuration suivante pour forcer SSL:
upstream jenkins-upstream {
server unproxied-jenkins.example.com:8080 fail_timeout=0;
}
server {
listen 80;
server_name proxied-jenkins.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443;
server_name proxied-jenkins.example.com;
#this is the jenkins web root directory (mentioned in the /etc/default/jenkins file)
root /var/run/jenkins/war/;
ssl on;
ssl_certificate /etc/nginx/conf.d/proxied-jenkins.example.com.crt;
ssl_certificate_key /etc/nginx/conf.d/proxied-jenkins.example.com.key;
ssl_protocols TLSv1.2;
ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
[...] # continuing according to jenkins documentation
location @jenkins {
proxy_pass http://jenkins-upstream
[....]
}
[....]
}
De nouveau lorsque vous passez à HTTP non sécurisé, JNLP et jenkins-cli fonctionnent comme prévu. Alors quelle est l'erreur?
Peut-être ai-je besoin de transmettre des informations d'en-tête supplémentaires? Peut-être ai-je besoin d'une configuration SSL supplémentaire dans mes paramètres de proxy?
javax.net.debug=sslfait le tour. J'ai pu découvrir que le binaire java (oracle jdk 7) avait essayé de manipuler le protocole TLSv1 avec des chiffrements "faibles" ... Après l'installation de Java Cryptography Extension (JCE), je disposais d'un meilleur support de chiffrement et j'étais capable de dire à java binaire à faire faire TLSv1.2. en utilisant -Dhttps.protocols=TLSv1.2. Cependant, après la mise à niveau vers Oracle JDK 8, cela fonctionne immédiatement. Je vous remercie donc de votre soutien et de m'avoir orienté dans la bonne direction ... Peut-être formulez-vous ceci comme réponse et je vais l'exclure et le faire passer au vote supérieur.
javax.net.debug=ssl, capturez la sortie (grande!) et ajoutez cela?